This seems to have been undocumented. Mention this where the name is set
(Builder::name) and where the panic could happen (Builder::spawn).
Thread::new is private and I think the builder is the only user where
this matters. A short comment was added to "document" Thread::new too.
* Moves docs about stack size and thread naming from `Builder` to the
`std::thread` module
* Adds more links to the new module-level documentation
* Mentions the 2 MiB stack size default, but indicate it's subject to
change
Fixes https://github.com/rust-lang/rust/issues/43805.
Check #[thread_local] statics correctly in the compiler.
Fixes#43733 by introducing `#[allow_internal_unsafe]` analogous to `#[allow_internal_unstable]`, for letting a macro expand to `unsafe` blocks and functions even in `#![forbid(unsafe_code)]` crates.
Fixes#17954 by not letting references to `#[thread_local]` statics escape the function they're taken in - we can't just use a magical lifetime because Rust has *lifetime parametrism*, so if we added the often-proposed `'thread` lifetime, we'd have no way to check it in generic code.
To avoid potential edge cases in the compiler, the lifetime is actually that of a temporary at the same position, i.e. `&TLS_STATIC` has the same lifetime `&non_const_fn()` would.
Referring to `#[thread_local]` `static`s at compile-time is banned now (as per PR discussion).
Additionally, to remove `unsafe impl Sync` from `std::thread::local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
support pub(restricted) in thread_local! (round 2)
Resurrected #40984 now that the issue blocking it was fixed. Original description:
`pub(restricted)` was stabilized in #40556 so let's go!
Here is a [playground](https://play.rust-lang.org/?gist=f55f32f164a6ed18c219fec8f8293b98&version=nightly&backtrace=1).
I changed the interface of `__thread_local_inner!`, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
[Doc] Expands `detach` documentation in `thread::JoinHande`.
Part of #29378 .
- Adds an example of a thread detaching.
- Expands what `detaching` means.
r? @steveklabnik
[Doc] Add `'static` and `Send` constraints explanations to `thread::spawn`
Part of #29378.
Explains why the constraints on the closure and its return value are `'static` and `Send`.
Allows to tick of `thread::spawn` from the list of things to document in the `thread` module.
r? @steveklabnik
[Doc] Add links to the `thread::LocalKey` doc.
Part of #29378 .
I do not know exactly what should be done for the `cleanup` part, if you have any idea I'll gladly do it.
r? @rust-lang/docs
[Doc] Implrove `thread::Builder`'s doc.
Part of #29378 .
- Explains *why* we would use the builder instead ofthe free function.
- Changes the parent-child explanation for a spawned-caller in `thread::Builder::spawn`
- Adds a link to `io::Result` in `thread::Builder`
- Corrects the return type doc in `thread::Builder::spawn`
r? @rust-lang/docs
Part of #29378 .
- In particular explains *why* we would use the builder instead of
the free function.
- Changes the parent-child explanation for a spawned-caller.
- Add link to `io::Result` in `thread::Builder`
- Corrects the `thread::Builder::spawn` documentation.
[Doc] Improve `thread::spawn` documentation
Part of #29378
- Add two examples to `thread::spawn` doumentation that show common uses of threads.
- Add a link to `thread::Builder` in the `thread::spawn` documentation for configuring threads.
- Add a link to `thread::spawn` in `thread::Builder` in order to avoid documentation duplication.
r? @steveklabnik
[DOC] Improve the thread::park and thread::unpark documentation
Part of #29378 .
Takes care of the documentation for `park`, `park_duration` and also improves the `unpark` example.
- `park should` have its module documentation inlined here, and cleaned up.
- `park_timeout` could use links to `park`.
Improve cleaning of the bottom of the backtrace
Following https://github.com/rust-lang/rust/pull/40264. It only cleans the bottom of the trace (after the main). It handles correctly the normal main, tests, benchmarks and threads.
I kept `skipped_before` since it will be used later for the cleaning of the top.
When `RUST_BACKTRACE=1`, remove all frames after
`__rust_maybe_catch_panic`. Tested on `main`, threads, tests and
benches. Cleaning of the top of the stacktrace is let to a future PR.
Fixes#40201
See #41815
Ulrik Sverdrup