nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2025-05-07 15:37:39 +00:00
Code Issues Packages Projects Releases Wiki Activity
c68c384b88
rust/library/std/src/thread/local.rs

1139 lines
41 KiB
Rust
Raw Normal View History

std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
//! Thread local storage
Implement RFC 909: move thread_local into thread This commit implements [RFC 909](https://github.com/rust-lang/rfcs/pull/909): The `std::thread_local` module is now deprecated, and its contents are available directly in `std::thread` as `LocalKey`, `LocalKeyState`, and `ScopedKey`. The macros remain exactly as they were, which means little if any code should break. Nevertheless, this is technically a: [breaking-change] Closes #23547
2015-03-20 07:46:13 +00:00
Require issue = "none" over issue = "0" in unstable attributes
2019-12-21 11:16:18 +00:00
#![unstable(feature = "thread_local_internals", issue = "none")]
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
std: move "mod tests/benches" to separate files Also doing fmt inplace as requested.
2020-08-27 13:45:01 +00:00
#[cfg(all(test, not(target_os = "emscripten")))]
mod tests;
#[cfg(test)]
mod dynamic_tests;
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
use crate::cell::{Cell, RefCell};
Add a few trait impls for AccessError
2019-06-03 16:20:38 +00:00
use crate::error::Error;
libstd => 2018
2019-02-10 19:23:21 +00:00
use crate::fmt;
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
/// A thread local storage key which owns its contents.
///
/// This key uses the fastest possible implementation available to it for the
Add links to the `thread::LocalKey` doc. Part of #29378 .
2017-05-14 18:06:54 +00:00
/// target platform. It is instantiated with the [`thread_local!`] macro and the
/// primary method is the [`with`] method.
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
Add links to the `thread::LocalKey` doc. Part of #29378 .
2017-05-14 18:06:54 +00:00
/// The [`with`] method yields a reference to the contained value which cannot be
Squeeze the last bits of `task`s in documentation in favor of `thread` An automated script was run against the `.rs` and `.md` files, subsituting every occurrence of `task` with `thread`. In the `.rs` files, only the texts in the comment blocks were affected.
2015-05-08 15:12:29 +00:00
/// sent across threads or escape the given closure.
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
/// # Initialization and Destruction
///
Add links to the `thread::LocalKey` doc. Part of #29378 .
2017-05-14 18:06:54 +00:00
/// Initialization is dynamically performed on the first call to [`with`]
/// within a thread, and values that implement [`Drop`] get destructed when a
Fix wording in LocalKey documentation
2017-02-15 22:26:29 +00:00
/// thread exits. Some caveats apply, which are explained below.
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
std::thread::LocalKey: Document limitation with initializers
2017-09-07 19:57:08 +00:00
/// A `LocalKey`'s initializer cannot recursively depend on itself, and using
/// a `LocalKey` in this way will cause the initializer to infinitely recurse
/// on the first call to `with`.
///
Example -> Examples This brings comments in line with https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md#using-markdown
2015-03-12 01:11:40 +00:00
/// # Examples
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
/// ```
/// use std::cell::RefCell;
Fallout from stabilization
2015-02-17 23:10:25 +00:00
/// use std::thread;
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
Integer audit in `libstd/thread_local/*`, part of #22240
2015-02-23 16:24:50 +00:00
/// thread_local!(static FOO: RefCell<u32> = RefCell::new(1));
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
/// FOO.with(|f| {
/// assert_eq!(*f.borrow(), 1);
/// *f.borrow_mut() = 2;
/// });
///
/// // each thread starts out with the initial value of 1
race condition in thread local storage example The example had a potential race condition that would still pass the test. If the thread which was supposed to modify it's own thread local was slower than the instruction to modify in the main thread, then the test would pass even in case of a failure. This is would be minor if the child thread was waited for since it check using an `assert_eq` for the same thing, but vice versa. However, if the `assert_eq` failed this would trigger a panic, which is not at all caught by the example since the thread is not waited on. Signed-off-by: benaryorg <binary@benary.org>
2019-03-03 14:21:52 +00:00
/// let t = thread::spawn(move|| {
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
/// FOO.with(|f| {
/// assert_eq!(*f.borrow(), 1);
/// *f.borrow_mut() = 3;
/// });
Fallout from stabilization
2015-01-06 05:59:45 +00:00
/// });
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
race condition in thread local storage example The example had a potential race condition that would still pass the test. If the thread which was supposed to modify it's own thread local was slower than the instruction to modify in the main thread, then the test would pass even in case of a failure. This is would be minor if the child thread was waited for since it check using an `assert_eq` for the same thing, but vice versa. However, if the `assert_eq` failed this would trigger a panic, which is not at all caught by the example since the thread is not waited on. Signed-off-by: benaryorg <binary@benary.org>
2019-03-03 14:21:52 +00:00
/// // wait for the thread to complete and bail out on panic
/// t.join().unwrap();
///
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
/// // we retain our original value of 2 despite the child thread
/// FOO.with(|f| {
/// assert_eq!(*f.borrow(), 2);
/// });
/// ```
std: Ignore dtors_in_dtors_in_dtors on OSX This test has been deadlocking and causing problems on the bots basically since its inception. Some memory safety issues were fixed in 987dc84b, but the deadlocks remained afterwards unfortunately. After some investigation, I've concluded that this is just a situation where OSX is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was rewriting the backing TLS memory to its initial state during destruction while we weren't looking, and this would have the effect of canceling the destructors of any other initialized TLS slots. While very difficult to pin down, this is basically what I assume is happening here, so there doesn't seem to really be anythig we can do to ensure the test robustly passes on OSX, so just ignore it for now.
2016-01-29 21:46:47 +00:00
///
/// # Platform-specific behavior
///
/// Note that a "best effort" is made to ensure that destructors for types
libstd: fix typos in thread::LocalKey docs
2016-04-25 20:01:19 +00:00
/// stored in thread local storage are run, but not all platforms can guarantee
std: Ignore dtors_in_dtors_in_dtors on OSX This test has been deadlocking and causing problems on the bots basically since its inception. Some memory safety issues were fixed in 987dc84b, but the deadlocks remained afterwards unfortunately. After some investigation, I've concluded that this is just a situation where OSX is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was rewriting the backing TLS memory to its initial state during destruction while we weren't looking, and this would have the effect of canceling the destructors of any other initialized TLS slots. While very difficult to pin down, this is basically what I assume is happening here, so there doesn't seem to really be anythig we can do to ensure the test robustly passes on OSX, so just ignore it for now.
2016-01-29 21:46:47 +00:00
/// that destructors will be run for all types in thread local storage. For
/// example, there are a number of known caveats where destructors are not run:
///
/// 1. On Unix systems when pthread-based TLS is being used, destructors will
/// not be run for TLS values on the main thread when it exits. Note that the
/// application will exit immediately after the main thread exits as well.
/// 2. On all platforms it's possible for TLS to re-initialize other TLS slots
/// during destruction. Some platforms ensure that this cannot happen
/// infinitely by preventing re-initialization of any slot that has been
/// destroyed, but not all platforms have this guard. Those platforms that do
/// not guard typically have a synthetic limit after which point no more
/// destructors are run.
Document Windows TLS drop behaviour
2021-12-02 13:52:35 +00:00
/// 3. When the process exits on Windows systems, TLS destructors may only be
/// run on the thread that causes the process to exit. This is because the
/// other threads may be forcibly terminated.
Add links to the `thread::LocalKey` doc. Part of #29378 .
2017-05-14 18:06:54 +00:00
///
Document Windows TLS drop behaviour
2021-12-02 13:52:35 +00:00
/// ## Synchronization in thread-local destructors
///
/// On Windows, synchronization operations (such as [`JoinHandle::join`]) in
/// thread local destructors are prone to deadlocks and so should be avoided.
/// This is because the [loader lock] is held while a destructor is run. The
/// lock is acquired whenever a thread starts or exits or when a DLL is loaded
/// or unloaded. Therefore these events are blocked for as long as a thread
/// local destructor is running.
///
/// [loader lock]: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices
/// [`JoinHandle::join`]: crate::thread::JoinHandle::join
Move to intra doc links for std::thread documentation
2020-08-20 20:03:00 +00:00
/// [`with`]: LocalKey::with
grandfathered -> rust1
2015-01-24 05:48:20 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
std: Use cfg(target_thread_local) in thread_local! This transitions the standard library's `thread_local!` macro to use the freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly simplifies the `#[cfg]` logic in play here, but requires that the standard library expose both the OS and ELF TLS implementation modules as unstable implementation details. The implementation details were shuffled around a bit but end up generally compiling to the same thing. Closes #26581 (this supersedes the need for the option) Closes #27057 (this also starts ignoring the option)
2015-12-11 20:42:29 +00:00
pub struct LocalKey<T: 'static> {
// This outer `LocalKey<T>` type is what's going to be stored in statics,
// but actual data inside will sometimes be tagged with #[thread_local].
// It's not valid for a true static to reference a #[thread_local] static,
// so we get around that by exposing an accessor through a layer of function
// indirection (this thunk).
//
// Note that the thunk is itself unsafe because the returned lifetime of the
// slot where data lives, `'static`, is not actually valid. The lifetime
Check #[thread_local] statics correctly in the compiler.
2017-08-08 15:22:51 +00:00
// here is actually slightly shorter than the currently running thread!
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
//
std: Use cfg(target_thread_local) in thread_local! This transitions the standard library's `thread_local!` macro to use the freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly simplifies the `#[cfg]` logic in play here, but requires that the standard library expose both the OS and ELF TLS implementation modules as unstable implementation details. The implementation details were shuffled around a bit but end up generally compiling to the same thing. Closes #26581 (this supersedes the need for the option) Closes #27057 (this also starts ignoring the option)
2015-12-11 20:42:29 +00:00
// Although this is an extra layer of indirection, it should in theory be
// trivially devirtualizable by LLVM because the value of `inner` never
// changes and the constant should be readonly within a crate. This mainly
// only runs into problems when TLS statics are exported across crates.
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
inner: unsafe fn(Option<&mut Option<T>>) -> Option<&'static T>,
librustc: Always parse `macro!()`/`macro![]` as expressions if not followed by a semicolon. This allows code like `vec![1i, 2, 3].len();` to work. This breaks code that uses macros as statements without putting semicolons after them, such as: fn main() { ... assert!(a == b) assert!(c == d) println(...); } It also breaks code that uses macros as items without semicolons: local_data_key!(foo) fn main() { println("hello world") } Add semicolons to fix this code. Those two examples can be fixed as follows: fn main() { ... assert!(a == b); assert!(c == d); println(...); } local_data_key!(foo); fn main() { println("hello world") } RFC #378. Closes #18635. [breaking-change]
2014-11-14 17:18:10 +00:00
}
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
Fix a few impl stability attributes The versions show up in rustdoc.
2017-01-29 13:31:47 +00:00
#[stable(feature = "std_debug", since = "1.16.0")]
Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.
2016-11-25 18:21:49 +00:00
impl<T: 'static> fmt::Debug for LocalKey<T> {
libstd: deny(elided_lifetimes_in_paths)
2019-03-01 08:34:11 +00:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
Replace all `fmt.pad` with `debug_struct`
2021-04-05 11:31:11 +00:00
f.debug_struct("LocalKey").finish_non_exhaustive()
Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.
2016-11-25 18:21:49 +00:00
}
}
Add links to the `thread::LocalKey` doc. Part of #29378 .
2017-05-14 18:06:54 +00:00
/// Declare a new thread local storage key of type [`std::thread::LocalKey`].
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
///
upgrade thread_local! invocation syntax Allows declaring multiple statics in one macro invocation, and supports attaching attributes to the generated items.
2016-06-04 19:19:22 +00:00
/// # Syntax
///
/// The macro wraps any number of static declarations and makes them thread local.
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
/// Publicity and attributes for each static are allowed. Example:
upgrade thread_local! invocation syntax Allows declaring multiple statics in one macro invocation, and supports attaching attributes to the generated items.
2016-06-04 19:19:22 +00:00
///
/// ```
/// use std::cell::RefCell;
/// thread_local! {
/// pub static FOO: RefCell<u32> = RefCell::new(1);
///
/// #[allow(unused)]
/// static BAR: RefCell<f32> = RefCell::new(1.0);
/// }
/// # fn main() {}
/// ```
///
Move to intra doc links for std::thread documentation
2020-08-20 20:03:00 +00:00
/// See [`LocalKey` documentation][`std::thread::LocalKey`] for more
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 06:24:27 +00:00
/// information.
Add links to the `thread::LocalKey` doc. Part of #29378 .
2017-05-14 18:06:54 +00:00
///
Move to intra doc links for std::thread documentation
2020-08-20 20:03:00 +00:00
/// [`std::thread::LocalKey`]: crate::thread::LocalKey
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
#[macro_export]
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
Add diagnostic items for macros
2022-01-06 14:50:46 +00:00
#[cfg_attr(not(test), rustc_diagnostic_item = "thread_local_macro")]
Bootstrap compiler update for 1.35 release
2019-02-27 23:58:12 +00:00
#[allow_internal_unstable(thread_local_internals)]
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 06:24:27 +00:00
macro_rules! thread_local {
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
// empty (base case for the recursion)
upgrade thread_local! invocation syntax Allows declaring multiple statics in one macro invocation, and supports attaching attributes to the generated items.
2016-06-04 19:19:22 +00:00
() => {};
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
$crate::__thread_local_inner!($(#[$attr])* $vis $name, $t, const $init);
$crate::thread_local!($($rest)*);
);
($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }) => (
$crate::__thread_local_inner!($(#[$attr])* $vis $name, $t, const $init);
);
use :vis in thread_local!
2017-04-19 02:29:40 +00:00
// process multiple declarations
($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = $init:expr; $($rest:tt)*) => (
std: Enable usage of `thread_local!` through imports The `thread_local!` macro delegated to an internal macro but it didn't do so in a macros-and-the-module-system compatible fashion, meaning if a `#![no_std]` crate imported `std` and tried to use `thread_local!` it would fail due to missing a lookup of an internal macro. This commit switches the macro to instead use `$crate` to invoke other macros, ensuring that it'll work when `thread_local!` is imported alone.
2018-11-01 21:17:39 +00:00
$crate::__thread_local_inner!($(#[$attr])* $vis $name, $t, $init);
$crate::thread_local!($($rest)*);
upgrade thread_local! invocation syntax Allows declaring multiple statics in one macro invocation, and supports attaching attributes to the generated items.
2016-06-04 19:19:22 +00:00
);
use :vis in thread_local!
2017-04-19 02:29:40 +00:00
// handle a single declaration
($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = $init:expr) => (
std: Enable usage of `thread_local!` through imports The `thread_local!` macro delegated to an internal macro but it didn't do so in a macros-and-the-module-system compatible fashion, meaning if a `#![no_std]` crate imported `std` and tried to use `thread_local!` it would fail due to missing a lookup of an internal macro. This commit switches the macro to instead use `$crate` to invoke other macros, ensuring that it'll work when `thread_local!` is imported alone.
2018-11-01 21:17:39 +00:00
$crate::__thread_local_inner!($(#[$attr])* $vis $name, $t, $init);
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 06:24:27 +00:00
);
}
#[doc(hidden)]
Require issue = "none" over issue = "0" in unstable attributes
2019-12-21 11:16:18 +00:00
#[unstable(feature = "thread_local_internals", reason = "should not be necessary", issue = "none")]
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 06:24:27 +00:00
#[macro_export]
Bootstrap compiler update for 1.35 release
2019-02-27 23:58:12 +00:00
#[allow_internal_unstable(thread_local_internals, cfg_target_thread_local, thread_local)]
Update bootstrap compiler This commit updates the bootstrap compiler and clears out a number of #[cfg(stage0)] annotations and related business
2017-08-25 15:39:02 +00:00
#[allow_internal_unsafe]
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 06:24:27 +00:00
macro_rules! __thread_local_inner {
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
// used to generate the `LocalKey` value for const-initialized thread locals
(@key $t:ty, const $init:expr) => {{
Make TLS __getit #[inline(always)] on non-Windows This may improve perf.
2022-02-25 20:21:27 +00:00
#[cfg_attr(not(windows), inline(always))] // see comments below
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
unsafe fn __getit(
_init: $crate::option::Option<&mut $crate::option::Option<$t>>,
) -> $crate::option::Option<&'static $t> {
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: https://github.com/rust-lang/rust/issues/84223#issuecomment-953384298
2021-11-10 18:55:30 +00:00
const INIT_EXPR: $t = $init;
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
// wasm without atomics maps directly to `static mut`, and dtors
// aren't implemented because thread dtors aren't really a thing
// on wasm right now
//
// FIXME(#84224) this should come after the `target_thread_local`
// block.
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
#[cfg(all(target_family = "wasm", not(target_feature = "atomics")))]
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
{
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: https://github.com/rust-lang/rust/issues/84223#issuecomment-953384298
2021-11-10 18:55:30 +00:00
static mut VAL: $t = INIT_EXPR;
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
Some(&VAL)
}
// If the platform has support for `#[thread_local]`, use it.
#[cfg(all(
target_thread_local,
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
not(all(target_family = "wasm", not(target_feature = "atomics"))),
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
))]
{
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: https://github.com/rust-lang/rust/issues/84223#issuecomment-953384298
2021-11-10 18:55:30 +00:00
#[thread_local]
static mut VAL: $t = INIT_EXPR;
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
// If a dtor isn't needed we can do something "very raw" and
// just get going.
if !$crate::mem::needs_drop::<$t>() {
unsafe {
return Some(&VAL)
}
}
// 0 == dtor not registered
// 1 == dtor registered, dtor not run
// 2 == dtor registered and is running or has run
#[thread_local]
static mut STATE: u8 = 0;
unsafe extern "C" fn destroy(ptr: *mut u8) {
let ptr = ptr as *mut $t;
unsafe {
debug_assert_eq!(STATE, 1);
STATE = 2;
$crate::ptr::drop_in_place(ptr);
}
}
unsafe {
match STATE {
// 0 == we haven't registered a destructor, so do
// so now.
0 => {
$crate::thread::__FastLocalKeyInner::<$t>::register_dtor(
fix aliasing violations in thread_local_const_init
2021-04-18 08:55:09 +00:00
$crate::ptr::addr_of_mut!(VAL) as *mut u8,
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
destroy,
);
STATE = 1;
Some(&VAL)
}
// 1 == the destructor is registered and the value
// is valid, so return the pointer.
1 => Some(&VAL),
// otherwise the destructor has already run, so we
// can't give access.
_ => None,
}
}
}
// On platforms without `#[thread_local]` we fall back to the
// same implementation as below for os thread locals.
#[cfg(all(
not(target_thread_local),
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
not(all(target_family = "wasm", not(target_feature = "atomics"))),
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
))]
{
#[inline]
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: https://github.com/rust-lang/rust/issues/84223#issuecomment-953384298
2021-11-10 18:55:30 +00:00
const fn __init() -> $t { INIT_EXPR }
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
static __KEY: $crate::thread::__OsLocalKeyInner<$t> =
$crate::thread::__OsLocalKeyInner::new();
#[allow(unused_unsafe)]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
unsafe {
__KEY.get(move || {
if let $crate::option::Option::Some(init) = _init {
if let $crate::option::Option::Some(value) = init.take() {
return value;
Add debug asserts in thread local cell set methods.
2021-12-20 18:20:56 +00:00
} else if $crate::cfg!(debug_assertions) {
unreachable!("missing initial value");
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
}
}
__init()
})
}
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
}
}
unsafe {
$crate::thread::LocalKey::new(__getit)
}
}};
// used to generate the `LocalKey` value for `thread_local!`
Update local.rs Removed parameters not used in the macro
2019-11-06 08:39:48 +00:00
(@key $t:ty, $init:expr) => {
Make the LocalKey facade of thread_local! inlineable cross-crate.
2017-08-13 13:42:10 +00:00
{
#[inline]
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
fn __init() -> $t { $init }
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-03 18:39:10 +00:00
// When reading this function you might ask "why is this inlined
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20 19:45:05 +00:00
// everywhere other than Windows?", and that's a very reasonable
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-03 18:39:10 +00:00
// question to ask. The short story is that it segfaults rustc if
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20 19:45:05 +00:00
// this function is inlined. The longer story is that Windows looks
// to not support `extern` references to thread locals across DLL
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-03 18:39:10 +00:00
// boundaries. This appears to at least not be supported in the ABI
// that LLVM implements.
//
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20 19:45:05 +00:00
// Because of this we never inline on Windows, but we do inline on
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-03 18:39:10 +00:00
// other platforms (where external references to thread locals
// across DLLs are supported). A better fix for this would be to
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20 19:45:05 +00:00
// inline this function on Windows, but only for "statically linked"
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-03 18:39:10 +00:00
// components. For example if two separately compiled rlibs end up
// getting linked into a DLL then it's fine to inline this function
// across that boundary. It's only not fine to inline this function
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20 19:45:05 +00:00
// across a DLL boundary. Unfortunately rustc doesn't currently
// have this sort of logic available in an attribute, and it's not
// clear that rustc is even equipped to answer this (it's more of a
// Cargo question kinda). This means that, unfortunately, Windows
// gets the pessimistic path for now where it's never inlined.
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-03 18:39:10 +00:00
//
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20 19:45:05 +00:00
// The issue of "should enable on Windows sometimes" is #84933
Make TLS __getit #[inline(always)] on non-Windows This may improve perf.
2022-02-25 20:21:27 +00:00
#[cfg_attr(not(windows), inline(always))]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
unsafe fn __getit(
init: $crate::option::Option<&mut $crate::option::Option<$t>>,
) -> $crate::option::Option<&'static $t> {
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
#[cfg(all(target_family = "wasm", not(target_feature = "atomics")))]
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
static __KEY: $crate::thread::__StaticLocalKeyInner<$t> =
$crate::thread::__StaticLocalKeyInner::new();
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
#[thread_local]
std: Implement TLS for wasm32-unknown-unknown This adds an implementation of thread local storage for the `wasm32-unknown-unknown` target when the `atomics` feature is implemented. This, however, comes with a notable caveat of that it requires a new feature of the standard library, `wasm-bindgen-threads`, to be enabled. Thread local storage for wasm (when `atomics` are enabled and there's actually more than one thread) is powered by the assumption that an external entity can fill in some information for us. It's not currently clear who will fill in this information nor whose responsibility it should be long-term. In the meantime there's a strategy being gamed out in the `wasm-bindgen` project specifically, and the hope is that we can continue to test and iterate on the standard library without committing to a particular strategy yet. As to the details of `wasm-bindgen`'s strategy, LLVM doesn't currently have the ability to emit custom `global` values (thread locals in a `WebAssembly.Module`) so we leverage the `wasm-bindgen` CLI tool to do it for us. To that end we have a few intrinsics, assuming two global values: * `__wbindgen_current_id` - gets the current thread id as a 32-bit integer. It's `wasm-bindgen`'s responsibility to initialize this per-thread and then inform libstd of the id. Currently `wasm-bindgen` performs this initialization as part of the `start` function. * `__wbindgen_tcb_{get,set}` - in addition to a thread id it's assumed that there's a global available for simply storing a pointer's worth of information (a thread control block, which currently only contains thread local storage). This would ideally be a native `global` injected by LLVM, but we don't have a great way to support that right now. To reiterate, this is all intended to be unstable and purely intended for testing out Rust on the web with threads. The story is very likely to change in the future and we want to make sure that we're able to do that!
2018-10-10 06:10:25 +00:00
#[cfg(all(
target_thread_local,
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
not(all(target_family = "wasm", not(target_feature = "atomics"))),
std: Implement TLS for wasm32-unknown-unknown This adds an implementation of thread local storage for the `wasm32-unknown-unknown` target when the `atomics` feature is implemented. This, however, comes with a notable caveat of that it requires a new feature of the standard library, `wasm-bindgen-threads`, to be enabled. Thread local storage for wasm (when `atomics` are enabled and there's actually more than one thread) is powered by the assumption that an external entity can fill in some information for us. It's not currently clear who will fill in this information nor whose responsibility it should be long-term. In the meantime there's a strategy being gamed out in the `wasm-bindgen` project specifically, and the hope is that we can continue to test and iterate on the standard library without committing to a particular strategy yet. As to the details of `wasm-bindgen`'s strategy, LLVM doesn't currently have the ability to emit custom `global` values (thread locals in a `WebAssembly.Module`) so we leverage the `wasm-bindgen` CLI tool to do it for us. To that end we have a few intrinsics, assuming two global values: * `__wbindgen_current_id` - gets the current thread id as a 32-bit integer. It's `wasm-bindgen`'s responsibility to initialize this per-thread and then inform libstd of the id. Currently `wasm-bindgen` performs this initialization as part of the `start` function. * `__wbindgen_tcb_{get,set}` - in addition to a thread id it's assumed that there's a global available for simply storing a pointer's worth of information (a thread control block, which currently only contains thread local storage). This would ideally be a native `global` injected by LLVM, but we don't have a great way to support that right now. To reiterate, this is all intended to be unstable and purely intended for testing out Rust on the web with threads. The story is very likely to change in the future and we want to make sure that we're able to do that!
2018-10-10 06:10:25 +00:00
))]
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
static __KEY: $crate::thread::__FastLocalKeyInner<$t> =
$crate::thread::__FastLocalKeyInner::new();
std: Implement TLS for wasm32-unknown-unknown This adds an implementation of thread local storage for the `wasm32-unknown-unknown` target when the `atomics` feature is implemented. This, however, comes with a notable caveat of that it requires a new feature of the standard library, `wasm-bindgen-threads`, to be enabled. Thread local storage for wasm (when `atomics` are enabled and there's actually more than one thread) is powered by the assumption that an external entity can fill in some information for us. It's not currently clear who will fill in this information nor whose responsibility it should be long-term. In the meantime there's a strategy being gamed out in the `wasm-bindgen` project specifically, and the hope is that we can continue to test and iterate on the standard library without committing to a particular strategy yet. As to the details of `wasm-bindgen`'s strategy, LLVM doesn't currently have the ability to emit custom `global` values (thread locals in a `WebAssembly.Module`) so we leverage the `wasm-bindgen` CLI tool to do it for us. To that end we have a few intrinsics, assuming two global values: * `__wbindgen_current_id` - gets the current thread id as a 32-bit integer. It's `wasm-bindgen`'s responsibility to initialize this per-thread and then inform libstd of the id. Currently `wasm-bindgen` performs this initialization as part of the `start` function. * `__wbindgen_tcb_{get,set}` - in addition to a thread id it's assumed that there's a global available for simply storing a pointer's worth of information (a thread control block, which currently only contains thread local storage). This would ideally be a native `global` injected by LLVM, but we don't have a great way to support that right now. To reiterate, this is all intended to be unstable and purely intended for testing out Rust on the web with threads. The story is very likely to change in the future and we want to make sure that we're able to do that!
2018-10-10 06:10:25 +00:00
#[cfg(all(
not(target_thread_local),
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
not(all(target_family = "wasm", not(target_feature = "atomics"))),
std: Implement TLS for wasm32-unknown-unknown This adds an implementation of thread local storage for the `wasm32-unknown-unknown` target when the `atomics` feature is implemented. This, however, comes with a notable caveat of that it requires a new feature of the standard library, `wasm-bindgen-threads`, to be enabled. Thread local storage for wasm (when `atomics` are enabled and there's actually more than one thread) is powered by the assumption that an external entity can fill in some information for us. It's not currently clear who will fill in this information nor whose responsibility it should be long-term. In the meantime there's a strategy being gamed out in the `wasm-bindgen` project specifically, and the hope is that we can continue to test and iterate on the standard library without committing to a particular strategy yet. As to the details of `wasm-bindgen`'s strategy, LLVM doesn't currently have the ability to emit custom `global` values (thread locals in a `WebAssembly.Module`) so we leverage the `wasm-bindgen` CLI tool to do it for us. To that end we have a few intrinsics, assuming two global values: * `__wbindgen_current_id` - gets the current thread id as a 32-bit integer. It's `wasm-bindgen`'s responsibility to initialize this per-thread and then inform libstd of the id. Currently `wasm-bindgen` performs this initialization as part of the `start` function. * `__wbindgen_tcb_{get,set}` - in addition to a thread id it's assumed that there's a global available for simply storing a pointer's worth of information (a thread control block, which currently only contains thread local storage). This would ideally be a native `global` injected by LLVM, but we don't have a great way to support that right now. To reiterate, this is all intended to be unstable and purely intended for testing out Rust on the web with threads. The story is very likely to change in the future and we want to make sure that we're able to do that!
2018-10-10 06:10:25 +00:00
))]
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
static __KEY: $crate::thread::__OsLocalKeyInner<$t> =
$crate::thread::__OsLocalKeyInner::new();
Disallow missing unsafe blocks in unsafe fn in panicking.rs This adds SAFETY comments where necessary, explaining the preconditions and how they are respected.
2020-07-29 19:58:09 +00:00
// FIXME: remove the #[allow(...)] marker when macros don't
// raise warning for missing/extraneous unsafe blocks anymore.
// See https://github.com/rust-lang/rust/issues/74838.
#[allow(unused_unsafe)]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
unsafe {
__KEY.get(move || {
if let $crate::option::Option::Some(init) = init {
if let $crate::option::Option::Some(value) = init.take() {
return value;
Add debug asserts in thread local cell set methods.
2021-12-20 18:20:56 +00:00
} else if $crate::cfg!(debug_assertions) {
unreachable!("missing default value");
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
}
}
__init()
})
}
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
}
Check #[thread_local] statics correctly in the compiler.
2017-08-08 15:22:51 +00:00
unsafe {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
$crate::thread::LocalKey::new(__getit)
Check #[thread_local] statics correctly in the compiler.
2017-08-08 15:22:51 +00:00
}
Make the LocalKey facade of thread_local! inlineable cross-crate.
2017-08-13 13:42:10 +00:00
}
};
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
($(#[$attr:meta])* $vis:vis $name:ident, $t:ty, $($init:tt)*) => {
Make the LocalKey facade of thread_local! inlineable cross-crate.
2017-08-13 13:42:10 +00:00
$(#[$attr])* $vis const $name: $crate::thread::LocalKey<$t> =
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
$crate::__thread_local_inner!(@key $t, $($init)*);
support pub(restricted) in thread_local!
2017-04-01 03:06:34 +00:00
}
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 06:24:27 +00:00
}
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
/// An error returned by [`LocalKey::try_with`](struct.LocalKey.html#method.try_with).
Stabilize LocalKey::try_with
2018-02-27 16:00:01 +00:00
#[stable(feature = "thread_local_try_with", since = "1.26.0")]
Use `#[non_exhaustive]` where appropriate Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`.
2021-06-24 08:16:11 +00:00
#[non_exhaustive]
Add a few trait impls for AccessError
2019-06-03 16:20:38 +00:00
#[derive(Clone, Copy, Eq, PartialEq)]
Use `#[non_exhaustive]` where appropriate Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`.
2021-06-24 08:16:11 +00:00
pub struct AccessError;
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
Stabilize LocalKey::try_with
2018-02-27 16:00:01 +00:00
#[stable(feature = "thread_local_try_with", since = "1.26.0")]
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
impl fmt::Debug for AccessError {
libstd: deny(elided_lifetimes_in_paths)
2019-03-01 08:34:11 +00:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
f.debug_struct("AccessError").finish()
}
}
Stabilize LocalKey::try_with
2018-02-27 16:00:01 +00:00
#[stable(feature = "thread_local_try_with", since = "1.26.0")]
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
impl fmt::Display for AccessError {
libstd: deny(elided_lifetimes_in_paths)
2019-03-01 08:34:11 +00:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
fmt::Display::fmt("already destroyed", f)
}
}
Add #[stable] to Error impl
2019-08-04 13:11:08 +00:00
#[stable(feature = "thread_local_try_with", since = "1.26.0")]
Add a few trait impls for AccessError
2019-06-03 16:20:38 +00:00
impl Error for AccessError {}
Implement RFC 909: move thread_local into thread This commit implements [RFC 909](https://github.com/rust-lang/rfcs/pull/909): The `std::thread_local` module is now deprecated, and its contents are available directly in `std::thread` as `LocalKey`, `LocalKeyState`, and `ScopedKey`. The macros remain exactly as they were, which means little if any code should break. Nevertheless, this is technically a: [breaking-change] Closes #23547
2015-03-20 07:46:13 +00:00
impl<T: 'static> LocalKey<T> {
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
#[doc(hidden)]
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
#[unstable(
feature = "thread_local_internals",
reason = "recently added to create a key",
Require issue = "none" over issue = "0" in unstable attributes
2019-12-21 11:16:18 +00:00
issue = "none"
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
)]
Update library functions with stability attributes This may not be strictly minimal, but all unstable functions also need a `rustc_const_unstable` attribute.
2020-09-17 18:02:56 +00:00
#[rustc_const_unstable(feature = "thread_local_internals", issue = "none")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub const unsafe fn new(
inner: unsafe fn(Option<&mut Option<T>>) -> Option<&'static T>,
) -> LocalKey<T> {
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
LocalKey { inner }
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
}
pluralize doc comment verbs and add missing periods
2015-04-13 14:21:32 +00:00
/// Acquires a reference to the value in this TLS key.
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
/// This function will `panic!()` if the key currently has its
/// destructor running, and it **may** panic if the destructor has
/// previously been run for this thread.
grandfathered -> rust1
2015-01-24 05:48:20 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
Avoid .take().unwrap() with FnOnce closures
2014-12-10 15:49:45 +00:00
pub fn with<F, R>(&'static self, f: F) -> R
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
where
F: FnOnce(&T) -> R,
{
self.try_with(f).expect(
"cannot access a Thread Local Storage value \
during or after destruction",
)
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
/// Acquires a reference to the value in this TLS key.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet. If the key has been destroyed (which may happen if this is called
Convert a bunch of intra-doc links
2020-11-07 20:22:24 +00:00
/// in a destructor), this function will return an [`AccessError`].
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
///
/// # Panics
///
/// This function will still `panic!()` if the key is uninitialized and the
/// key's initializer panics.
Stabilize LocalKey::try_with
2018-02-27 16:00:01 +00:00
#[stable(feature = "thread_local_try_with", since = "1.26.0")]
Add inline attributes for functions used in the query system
2020-03-30 12:36:28 +00:00
#[inline]
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
pub fn try_with<F, R>(&'static self, f: F) -> Result<R, AccessError>
Stabilize LocalKey::try_with
2018-02-27 16:00:01 +00:00
where
F: FnOnce(&T) -> R,
{
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
unsafe {
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
let thread_local = (self.inner)(None).ok_or(AccessError)?;
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
Ok(f(thread_local))
}
}
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
Update documentation in thread/local.rs.
2021-12-20 18:21:36 +00:00
/// Acquires a reference to the value in this TLS key, initializing it with
/// `init` if it wasn't already initialized on this thread.
///
/// If `init` was used to initialize the thread local variable, `None` is
/// passed as the first argument to `f`. If it was already initialized,
/// `Some(init)` is passed to `f`.
///
/// # Panics
///
/// This function will panic if the key currently has its destructor
/// running, and it **may** panic if the destructor has previously been run
/// for this thread.
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
fn initialize_with<F, R>(&'static self, init: T, f: F) -> R
where
F: FnOnce(Option<T>, &T) -> R,
{
unsafe {
let mut init = Some(init);
let reference = (self.inner)(Some(&mut init)).expect(
"cannot access a Thread Local Storage value \
during or after destruction",
);
f(init, reference)
}
}
}
impl<T: 'static> LocalKey<Cell<T>> {
/// Sets or initializes the contained value.
///
/// Unlike the other methods, this will *not* run the lazy initializer of
/// the thread local. Instead, it will be directly initialized with the
/// given value if it wasn't initialized yet.
///
/// # Panics
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::Cell;
///
/// thread_local! {
/// static X: Cell<i32> = panic!("!");
/// }
///
/// // Calling X.get() here would result in a panic.
///
/// X.set(123); // But X.set() is fine, as it skips the initializer above.
///
/// assert_eq!(X.get(), 123);
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn set(&'static self, value: T) {
Update documentation in thread/local.rs.
2021-12-20 18:21:36 +00:00
self.initialize_with(Cell::new(value), |value, cell| {
if let Some(value) = value {
// The cell was already initialized, so `value` wasn't used to
// initialize it. So we overwrite the current value with the
// new one instead.
cell.set(value.into_inner());
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
}
});
}
/// Returns a copy of the contained value.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::Cell;
///
/// thread_local! {
/// static X: Cell<i32> = Cell::new(1);
/// }
///
/// assert_eq!(X.get(), 1);
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn get(&'static self) -> T
where
T: Copy,
{
self.with(|cell| cell.get())
}
/// Takes the contained value, leaving `Default::default()` in its place.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::Cell;
///
/// thread_local! {
/// static X: Cell<Option<i32>> = Cell::new(Some(1));
/// }
///
/// assert_eq!(X.take(), Some(1));
/// assert_eq!(X.take(), None);
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn take(&'static self) -> T
where
T: Default,
{
self.with(|cell| cell.take())
}
/// Replaces the contained value, returning the old value.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::Cell;
///
/// thread_local! {
/// static X: Cell<i32> = Cell::new(1);
/// }
///
/// assert_eq!(X.replace(2), 1);
/// assert_eq!(X.replace(3), 2);
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn replace(&'static self, value: T) -> T {
self.with(|cell| cell.replace(value))
}
}
impl<T: 'static> LocalKey<RefCell<T>> {
/// Acquires a reference to the contained value.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
Update documentation in thread/local.rs.
2021-12-20 18:21:36 +00:00
/// Panics if the value is currently mutably borrowed.
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Example
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::RefCell;
///
/// thread_local! {
/// static X: RefCell<Vec<i32>> = RefCell::new(Vec::new());
/// }
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow(|v| assert!(v.is_empty()));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
pub fn with_borrow<F, R>(&'static self, f: F) -> R
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
where
F: FnOnce(&T) -> R,
{
self.with(|cell| f(&mut cell.borrow()))
}
/// Acquires a mutable reference to the contained value.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
/// Panics if the value is currently borrowed.
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Example
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::RefCell;
///
/// thread_local! {
/// static X: RefCell<Vec<i32>> = RefCell::new(Vec::new());
/// }
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow_mut(|v| v.push(1));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow(|v| assert_eq!(*v, vec![1]));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
pub fn with_borrow_mut<F, R>(&'static self, f: F) -> R
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
where
F: FnOnce(&mut T) -> R,
{
self.with(|cell| f(&mut cell.borrow_mut()))
}
/// Sets or initializes the contained value.
///
/// Unlike the other methods, this will *not* run the lazy initializer of
/// the thread local. Instead, it will be directly initialized with the
/// given value if it wasn't initialized yet.
///
/// # Panics
///
Update documentation in thread/local.rs.
2021-12-20 18:21:36 +00:00
/// Panics if the value is currently borrowed.
///
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::RefCell;
///
/// thread_local! {
/// static X: RefCell<Vec<i32>> = panic!("!");
/// }
///
/// // Calling X.with() here would result in a panic.
///
/// X.set(vec![1, 2, 3]); // But X.set() is fine, as it skips the initializer above.
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow(|v| assert_eq!(*v, vec![1, 2, 3]));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn set(&'static self, value: T) {
Update documentation in thread/local.rs.
2021-12-20 18:21:36 +00:00
self.initialize_with(RefCell::new(value), |value, cell| {
if let Some(value) = value {
// The cell was already initialized, so `value` wasn't used to
// initialize it. So we overwrite the current value with the
// new one instead.
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
cell.replace(init.into_inner());
}
});
}
/// Takes the contained value, leaving `Default::default()` in its place.
///
/// This will lazily initialize the value if this thread has not referenced
/// this key yet.
///
/// # Panics
///
/// Panics if the value is currently borrowed.
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::RefCell;
///
/// thread_local! {
/// static X: RefCell<Vec<i32>> = RefCell::new(Vec::new());
/// }
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow_mut(|v| v.push(1));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
///
/// let a = X.take();
///
/// assert_eq!(a, vec![1]);
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow(|v| assert!(v.is_empty()));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn take(&'static self) -> T
where
T: Default,
{
self.with(|cell| cell.take())
}
/// Replaces the contained value, returning the old value.
///
/// # Panics
///
/// Panics if the value is currently borrowed.
///
/// Panics if the key currently has its destructor running,
/// and it **may** panic if the destructor has previously been run for this thread.
///
/// # Examples
///
/// ```
/// #![feature(local_key_cell_methods)]
/// use std::cell::RefCell;
///
/// thread_local! {
/// static X: RefCell<Vec<i32>> = RefCell::new(Vec::new());
/// }
///
/// let prev = X.replace(vec![1, 2, 3]);
/// assert!(prev.is_empty());
///
Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.
2021-12-20 12:38:07 +00:00
/// X.with_borrow(|v| assert_eq!(*v, vec![1, 2, 3]));
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
/// ```
Add tracking issue number for local_key_cell_methods.
2021-12-20 12:49:10 +00:00
#[unstable(feature = "local_key_cell_methods", issue = "92122")]
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub fn replace(&'static self, value: T) -> T {
self.with(|cell| cell.replace(value))
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
mod lazy {
use crate::cell::UnsafeCell;
use crate::hint;
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
use crate::mem;
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
pub struct LazyKeyInner<T> {
inner: UnsafeCell<Option<T>>,
}
impl<T> LazyKeyInner<T> {
pub const fn new() -> LazyKeyInner<T> {
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
LazyKeyInner { inner: UnsafeCell::new(None) }
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
pub unsafe fn get(&self) -> Option<&'static T> {
Fix accordingly to review
2020-09-20 15:31:55 +00:00
// SAFETY: The caller must ensure no reference is ever handed out to
// the inner cell nor mutable reference to the Option<T> inside said
// cell. This make it safe to hand a reference, though the lifetime
// of 'static is itself unsafe, making the get method unsafe.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe { (*self.inner.get()).as_ref() }
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
Fix accordingly to review
2020-09-20 15:31:55 +00:00
/// The caller must ensure that no reference is active: this method
/// needs unique access.
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
pub unsafe fn initialize<F: FnOnce() -> T>(&self, init: F) -> &'static T {
// Execute the initialization up front, *then* move it into our slot,
// just in case initialization fails.
let value = init();
let ptr = self.inner.get();
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
// SAFETY:
//
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
// note that this can in theory just be `*ptr = Some(value)`, but due to
// the compiler will currently codegen that pattern with something like:
//
// ptr::drop_in_place(ptr)
// ptr::write(ptr, Some(value))
//
// Due to this pattern it's possible for the destructor of the value in
// `ptr` (e.g., if this is being recursively initialized) to re-access
// TLS, in which case there will be a `&` and `&mut` pointer to the same
// value (an aliasing violation). To avoid setting the "I'm running a
// destructor" flag we just use `mem::replace` which should sequence the
// operations a little differently and make this safe to call.
Improve some SAFETY comments following suggestions
2020-08-29 18:10:05 +00:00
//
Fix accordingly to review
2020-09-20 15:31:55 +00:00
// The precondition also ensures that we are the only one accessing
// `self` at the moment so replacing is fine.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe {
let _ = mem::replace(&mut *ptr, Some(value));
}
Fix accordingly to review
2020-09-20 15:31:55 +00:00
// SAFETY: With the call to `mem::replace` it is guaranteed there is
Improve some SAFETY comments following suggestions
2020-08-29 18:10:05 +00:00
// a `Some` behind `ptr`, not a `None` so `unreachable_unchecked`
// will never be reached.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe {
// After storing `Some` we want to get a reference to the contents of
// what we just stored. While we could use `unwrap` here and it should
// always work it empirically doesn't seem to always get optimized away,
// which means that using something like `try_with` can pull in
// panicking code and cause a large size bloat.
match *ptr {
Some(ref x) => x,
None => hint::unreachable_unchecked(),
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
}
Fix accordingly to review
2020-09-20 15:31:55 +00:00
/// The other methods hand out references while taking &self.
/// As such, callers of this method must ensure no `&` and `&mut` are
/// available and used at the same time.
add #[allow(unused)]
2019-05-04 00:01:53 +00:00
#[allow(unused)]
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
pub unsafe fn take(&mut self) -> Option<T> {
Fix accordingly to review
2020-09-20 15:31:55 +00:00
// SAFETY: See doc comment for this method.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe { (*self.inner.get()).take() }
Add LocalKey::try_with as an alternative to state
2017-07-10 23:26:11 +00:00
}
}
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
Review comments
2021-11-01 14:11:05 +00:00
/// On some targets like wasm there's no threads, so no need to generate
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
/// thread locals and we can instead just use plain statics!
#[doc(hidden)]
Use `target_family = "wasm"`
2021-10-28 23:28:21 +00:00
#[cfg(all(target_family = "wasm", not(target_feature = "atomics")))]
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
pub mod statik {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
use super::lazy::LazyKeyInner;
libstd => 2018
2019-02-10 19:23:21 +00:00
use crate::fmt;
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
pub struct Key<T> {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
inner: LazyKeyInner<T>,
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
}
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
unsafe impl<T> Sync for Key<T> {}
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
impl<T> fmt::Debug for Key<T> {
libstd: deny(elided_lifetimes_in_paths)
2019-03-01 08:34:11 +00:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
Replace all `fmt.pad` with `debug_struct`
2021-04-05 11:31:11 +00:00
f.debug_struct("Key").finish_non_exhaustive()
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
}
}
impl<T> Key<T> {
pub const fn new() -> Key<T> {
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
Key { inner: LazyKeyInner::new() }
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
}
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub unsafe fn get(&self, init: impl FnOnce() -> T) -> Option<&'static T> {
Fix missing unsafe block for target arch wasm32
2020-09-21 21:08:48 +00:00
// SAFETY: The caller must ensure no reference is ever handed out to
// the inner cell nor mutable reference to the Option<T> inside said
// cell. This make it safe to hand a reference, though the lifetime
// of 'static is itself unsafe, making the get method unsafe.
let value = unsafe {
match self.inner.get() {
Some(ref value) => value,
None => self.inner.initialize(init),
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
};
Fix missing unsafe block for target arch wasm32
2020-09-21 21:08:48 +00:00
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
Some(value)
std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-03-29 21:59:13 +00:00
}
}
}
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
#[doc(hidden)]
#[cfg(target_thread_local)]
pub mod fast {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
use super::lazy::LazyKeyInner;
use crate::cell::Cell;
libstd => 2018
2019-02-10 19:23:21 +00:00
use crate::fmt;
use crate::mem;
rename fast_thread_local -> thread_local_dtor; thread_local -> thread_local_key
2020-07-12 09:37:11 +00:00
use crate::sys::thread_local_dtor::register_dtor;
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
#[derive(Copy, Clone)]
enum DtorState {
Unregistered,
Registered,
RunningOrHasRun,
}
- remove unnecessary inlines - add comment explaining that the fast::Key data structure was carefully constructed for fast access on OSX - remove inline(never) from the initializer for types where `needs_drop::<T>()` is false
2019-05-11 00:29:43 +00:00
// This data structure has been carefully constructed so that the fast path
// only contains one branch on x86. That optimization is necessary to avoid
// duplicated tls lookups on OSX.
remove trailing whitespace
2019-05-11 17:42:44 +00:00
//
- remove unnecessary inlines - add comment explaining that the fast::Key data structure was carefully constructed for fast access on OSX - remove inline(never) from the initializer for types where `needs_drop::<T>()` is false
2019-05-11 00:29:43 +00:00
// LLVM issue: https://bugs.llvm.org/show_bug.cgi?id=41722
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
pub struct Key<T> {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
// If `LazyKeyInner::get` returns `None`, that indicates either:
// * The value has never been initialized
// * The value is being recursively initialized
// * The value has already been destroyed or is being destroyed
// To determine which kind of `None`, check `dtor_state`.
//
// This is very optimizer friendly for the fast path - initialized but
// not yet dropped.
inner: LazyKeyInner<T>,
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
// Metadata to keep track of the state of the destructor. Remember that
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
// this variable is thread-local, not global.
dtor_state: Cell<DtorState>,
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
}
impl<T> fmt::Debug for Key<T> {
libstd: deny(elided_lifetimes_in_paths)
2019-03-01 08:34:11 +00:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
Replace all `fmt.pad` with `debug_struct`
2021-04-05 11:31:11 +00:00
f.debug_struct("Key").finish_non_exhaustive()
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
}
}
impl<T> Key<T> {
pub const fn new() -> Key<T> {
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
Key { inner: LazyKeyInner::new(), dtor_state: Cell::new(DtorState::Unregistered) }
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
}
Fix a bunch of typos
2021-12-14 14:23:34 +00:00
// note that this is just a publicly-callable function only for the
std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-23 18:04:29 +00:00
// const-initialized form of thread locals, basically a way to call the
// free `register_dtor` function defined elsewhere in libstd.
pub unsafe fn register_dtor(a: *mut u8, dtor: unsafe extern "C" fn(*mut u8)) {
unsafe {
register_dtor(a, dtor);
}
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
pub unsafe fn get<F: FnOnce() -> T>(&self, init: F) -> Option<&'static T> {
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
// SAFETY: See the definitions of `LazyKeyInner::get` and
Fix a bunch of typos
2021-12-14 14:23:34 +00:00
// `try_initialize` for more information.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
//
Fix accordingly to review
2020-09-20 15:31:55 +00:00
// The caller must ensure no mutable references are ever active to
// the inner cell or the inner T when this is called.
// The `try_initialize` is dependant on the passed `init` function
// for this.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe {
match self.inner.get() {
Some(val) => Some(val),
None => self.try_initialize(init),
}
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
}
}
- remove unnecessary inlines - add comment explaining that the fast::Key data structure was carefully constructed for fast access on OSX - remove inline(never) from the initializer for types where `needs_drop::<T>()` is false
2019-05-11 00:29:43 +00:00
// `try_initialize` is only called once per fast thread local variable,
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
// except in corner cases where thread_local dtors reference other
// thread_local's, or it is being recursively initialized.
//
// Macos: Inlining this function can cause two `tlv_get_addr` calls to
Use inline(never) instead of cold inline(never) is better way to avoid optimizer to inline the function instead of cold.
2020-09-02 22:31:21 +00:00
// be performed for every call to `Key::get`.
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
// LLVM issue: https://bugs.llvm.org/show_bug.cgi?id=41722
Use inline(never) instead of cold inline(never) is better way to avoid optimizer to inline the function instead of cold.
2020-09-02 22:31:21 +00:00
#[inline(never)]
- remove unnecessary inlines - add comment explaining that the fast::Key data structure was carefully constructed for fast access on OSX - remove inline(never) from the initializer for types where `needs_drop::<T>()` is false
2019-05-11 00:29:43 +00:00
unsafe fn try_initialize<F: FnOnce() -> T>(&self, init: F) -> Option<&'static T> {
Improve some SAFETY comments following suggestions
2020-08-29 18:10:05 +00:00
// SAFETY: See comment above (this function doc).
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
if !mem::needs_drop::<T>() || unsafe { self.try_register_dtor() } {
Improve some SAFETY comments following suggestions
2020-08-29 18:10:05 +00:00
// SAFETY: See comment above (his function doc).
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
Some(unsafe { self.inner.initialize(init) })
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
} else {
None
- remove unnecessary inlines - add comment explaining that the fast::Key data structure was carefully constructed for fast access on OSX - remove inline(never) from the initializer for types where `needs_drop::<T>()` is false
2019-05-11 00:29:43 +00:00
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
// `try_register_dtor` is only called once per fast thread local
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
// variable, except in corner cases where thread_local dtors reference
// other thread_local's, or it is being recursively initialized.
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
unsafe fn try_register_dtor(&self) -> bool {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
match self.dtor_state.get() {
DtorState::Unregistered => {
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
// SAFETY: dtor registration happens before initialization.
// Passing `self` as a pointer while using `destroy_value<T>`
// is safe because the function will build a pointer to a
// Key<T>, which is the type of self and so find the correct
// size.
unsafe { register_dtor(self as *const _ as *mut u8, destroy_value::<T>) };
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
self.dtor_state.set(DtorState::Registered);
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
true
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
DtorState::Registered => {
// recursively initialized
llvm makes good inlining choices with only the #[cold] attribute
2019-05-15 14:18:24 +00:00
true
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
DtorState::RunningOrHasRun => false,
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
}
}
}
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
unsafe extern "C" fn destroy_value<T>(ptr: *mut u8) {
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
let ptr = ptr as *mut Key<T>;
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
// SAFETY:
//
// The pointer `ptr` has been built just above and comes from
// `try_register_dtor` where it is originally a Key<T> coming from `self`,
// making it non-NUL and of the correct type.
//
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
// Right before we run the user destructor be sure to set the
// `Option<T>` to `None`, and `dtor_state` to `RunningOrHasRun`. This
// causes future calls to `get` to run `try_initialize_drop` again,
// which will now fail, and return `None`.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe {
let value = (*ptr).inner.take();
(*ptr).dtor_state.set(DtorState::RunningOrHasRun);
drop(value);
}
rustc: Enable #[thread_local] for Windows 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.
2016-02-17 07:07:09 +00:00
}
}
std: Clean up some annotations in thread::local Don't need so much manual #[doc(hidden)] and #[unstable] as much of it is inherited!
2015-04-15 19:26:27 +00:00
#[doc(hidden)]
std: Use cfg(target_thread_local) in thread_local! This transitions the standard library's `thread_local!` macro to use the freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly simplifies the `#[cfg]` logic in play here, but requires that the standard library expose both the OS and ELF TLS implementation modules as unstable implementation details. The implementation details were shuffled around a bit but end up generally compiling to the same thing. Closes #26581 (this supersedes the need for the option) Closes #27057 (this also starts ignoring the option)
2015-12-11 20:42:29 +00:00
pub mod os {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
use super::lazy::LazyKeyInner;
use crate::cell::Cell;
libstd => 2018
2019-02-10 19:23:21 +00:00
use crate::fmt;
use crate::marker;
use crate::ptr;
rename fast_thread_local -> thread_local_dtor; thread_local -> thread_local_key
2020-07-12 09:37:11 +00:00
use crate::sys_common::thread_local_key::StaticKey as OsStaticKey;
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
pub struct Key<T> {
// OS-TLS key that we'll use to key off.
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
os: OsStaticKey,
marker: marker::PhantomData<Cell<T>>,
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.
2016-11-25 18:21:49 +00:00
impl<T> fmt::Debug for Key<T> {
libstd: deny(elided_lifetimes_in_paths)
2019-03-01 08:34:11 +00:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
Replace all `fmt.pad` with `debug_struct`
2021-04-05 11:31:11 +00:00
f.debug_struct("Key").finish_non_exhaustive()
Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.
2016-11-25 18:21:49 +00:00
}
}
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
unsafe impl<T> Sync for Key<T> {}
Require types to opt-in Sync
2014-12-06 16:39:25 +00:00
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
struct Value<T: 'static> {
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
inner: LazyKeyInner<T>,
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
key: &'static Key<T>,
}
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
impl<T: 'static> Key<T> {
Update library functions with stability attributes This may not be strictly minimal, but all unstable functions also need a `rustc_const_unstable` attribute.
2020-09-17 18:02:56 +00:00
#[rustc_const_unstable(feature = "thread_local_internals", issue = "none")]
Use `const fn` to abstract away the contents of UnsafeCell & friends.
2015-05-27 08:18:36 +00:00
pub const fn new() -> Key<T> {
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
Key { os: OsStaticKey::new(Some(destroy_value::<T>)), marker: marker::PhantomData }
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
Fix accordingly to review
2020-09-20 15:31:55 +00:00
/// It is a requirement for the caller to ensure that no mutable
/// reference is active when this method is called.
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
pub unsafe fn get(&'static self, init: impl FnOnce() -> T) -> Option<&'static T> {
Fix accordingly to review
2020-09-20 15:31:55 +00:00
// SAFETY: See the documentation for this method.
Finished documenting all unsafe op inside unsafe fn
2020-07-10 22:15:24 +00:00
let ptr = unsafe { self.os.get() as *mut Value<T> };
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
if ptr as usize > 1 {
Finished documenting all unsafe op inside unsafe fn
2020-07-10 22:15:24 +00:00
// SAFETY: the check ensured the pointer is safe (its destructor
// is not running) + it is coming from a trusted source (self).
if let Some(ref value) = unsafe { (*ptr).inner.get() } {
Apply clippy::single_match suggestion
2019-09-05 12:08:06 +00:00
return Some(value);
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
Finished documenting all unsafe op inside unsafe fn
2020-07-10 22:15:24 +00:00
// SAFETY: At this point we are sure we have no value and so
// initializing (or trying to) is safe.
unsafe { self.try_initialize(init) }
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
}
// `try_initialize` is only called once per os thread local variable,
// except in corner cases where thread_local dtors reference other
// thread_local's, or it is being recursively initialized.
Implement RFC 3184 - thread local cell methods.
2021-10-19 12:37:27 +00:00
unsafe fn try_initialize(&'static self, init: impl FnOnce() -> T) -> Option<&'static T> {
Finished documenting all unsafe op inside unsafe fn
2020-07-10 22:15:24 +00:00
// SAFETY: No mutable references are ever handed out meaning getting
// the value is ok.
let ptr = unsafe { self.os.get() as *mut Value<T> };
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
if ptr as usize == 1 {
// destructor is running
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
return None;
Stop using unsafe code in TLS macro expansion (fixes #30756)
2016-02-04 12:20:20 +00:00
}
Check #[thread_local] statics correctly in the compiler.
2017-08-08 15:22:51 +00:00
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
let ptr = if ptr.is_null() {
// If the lookup returned null, we haven't initialized our own
// local copy, so do that now.
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
let ptr: Box<Value<T>> = box Value { inner: LazyKeyInner::new(), key: self };
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
let ptr = Box::into_raw(ptr);
Finished documenting all unsafe op inside unsafe fn
2020-07-10 22:15:24 +00:00
// SAFETY: At this point we are sure there is no value inside
// ptr so setting it will not affect anyone else.
unsafe {
self.os.set(ptr as *mut u8);
}
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
ptr
} else {
// recursive initialization
ptr
Check #[thread_local] statics correctly in the compiler.
2017-08-08 15:22:51 +00:00
};
restructure thread_local! for better codegen (especially on macos)
2019-05-03 05:40:52 +00:00
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
// SAFETY: ptr has been ensured as non-NUL just above an so can be
// dereferenced safely.
unsafe { Some((*ptr).inner.initialize(init)) }
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
}
Format libstd with rustfmt This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-27 18:29:00 +00:00
unsafe extern "C" fn destroy_value<T: 'static>(ptr: *mut u8) {
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
// SAFETY:
//
Change 'NULL' to 'null'
2021-05-02 21:55:22 +00:00
// The OS TLS ensures that this key contains a null value when this
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
// destructor starts to run. We set it back to a sentinel value of 1 to
// ensure that any future calls to `get` for this thread will return
// `None`.
//
// Note that to prevent an infinite loop we reset it back to null right
// before we return from the destructor ourselves.
Deny unsafe op in unsafe fns without the unsafe keyword, first part for std/thread
2020-07-10 21:53:25 +00:00
unsafe {
let ptr = Box::from_raw(ptr as *mut Value<T>);
let key = ptr.key;
key.os.set(1 as *mut u8);
drop(ptr);
key.os.set(ptr::null_mut());
}
std: Add a new top-level thread_local module This commit removes the `std::local_data` module in favor of a new `std::thread_local` module providing thread local storage. The module provides two variants of TLS: one which owns its contents and one which is based on scoped references. Each implementation has pros and cons listed in the documentation. Both flavors have accessors through a function called `with` which yield a reference to a closure provided. Both flavors also panic if a reference cannot be yielded and provide a function to test whether an access would panic or not. This is an implementation of [RFC 461][rfc] and full details can be found in that RFC. This is a breaking change due to the removal of the `std::local_data` module. All users can migrate to the new thread local system like so: thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None))) The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as an implementation detail which must now be explicitly stated by users. [rfc]: https://github.com/rust-lang/rfcs/pull/461 [breaking-change]
2014-11-14 22:20:57 +00:00
}
}
Reference in New Issue Copy Permalink