-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest using a lock for *Cell: Sync
bounds
#106944
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like the std::rc
and std::cell
module docs, I think it would be better if we add some qualification:
if you want to do aliasing and mutation between multiple threads, use X instead
because I'm not sure this suggestion is always the right thing to do - I've seen two scenarios when users hit this error:
- They're designing something multithreaded and really should be using Mutex/RwLock, not RefCell
- They're designing something singlethreaded and accidentally use the type in a context requiring Sync, in which case they shouldn't do that.
library/core/src/marker.rs
Outdated
on(_Self = "std::cell::OnceCell<T>", note = "use `std::sync::OnceLock` instead"), | ||
on( | ||
_Self = "std::cell::Cell<T>", | ||
note = "use `std::sync::RwLock` or an atomic variable instead", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or an atomic variable instead
Do you mean an atomic integer? That'll only map with Cell<{integer}>
where integer != i128/u128
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we do
on(_Self = "std::cell::Cell<bool>", note = "...AtomicBool..."),
on(_Self = "std::cell::Cell<u8>", note = "...AtomicU8..."),
...
?
Suggest using a lock instead.
231f061
to
6d0c91f
Compare
// Just like for `Cell<T>` this isn't needed, but results in nicer error messages. | ||
#[unstable(feature = "once_cell", issue = "74465")] | ||
impl<T> !Sync for OnceCell<T> {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually... Removing this would be a breaking change: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=1f4ad2c6d839ce8a21237c4faa7b2e9e (tl;dr: you'll be able to impl trait for <T: Sync>
and OnceCell
).
Should we consult t-libs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not believe so (I'm not totally sure) - coherence only lets you do this in the crate where S
is defined, for now there is no (stable) way to rely on a negative impl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this is easy to prove: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=1ff2fdaa8ed22c14e94aaddb348ab850.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it is said to be a breaking change by the docs: https://doc.rust-lang.org/beta/unstable-book/language-features/negative-impls.html, so I'm again not sure about this.
@bors r+ |
…tic, r=WaffleLapkin Suggest using a lock for `*Cell: Sync` bounds I mostly did this for `OnceCell<T>` at first because users will be confused to see that the `OnceCell<T>` in `std` isn't `Sync` but then extended it to `Cell<T>` and `RefCell<T>` as well.
…tic, r=WaffleLapkin Suggest using a lock for `*Cell: Sync` bounds I mostly did this for `OnceCell<T>` at first because users will be confused to see that the `OnceCell<T>` in `std` isn't `Sync` but then extended it to `Cell<T>` and `RefCell<T>` as well.
…tic, r=WaffleLapkin Suggest using a lock for `*Cell: Sync` bounds I mostly did this for `OnceCell<T>` at first because users will be confused to see that the `OnceCell<T>` in `std` isn't `Sync` but then extended it to `Cell<T>` and `RefCell<T>` as well.
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#105345 (Add hint for missing lifetime bound on trait object when type alias is used) - rust-lang#106897 (Tweak E0597) - rust-lang#106944 (Suggest using a lock for `*Cell: Sync` bounds) - rust-lang#107239 (Bring tests back into rustc source tarball) - rust-lang#107244 (rustdoc: rearrange HTML in primitive reference links) - rust-lang#107255 (add test where we ignore hr implied bounds) - rust-lang#107256 (Delete `SimplifyArmIdentity` and `SimplifyBranchSame` mir opts) - rust-lang#107266 (rustdoc: prohibit scroll bar on source viewer in Safari) - rust-lang#107282 (erica solver: implement builtin `Pointee` trait impl candidates) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
I mostly did this for
OnceCell<T>
at first because users will be confused to see that theOnceCell<T>
instd
isn'tSync
but then extended it toCell<T>
andRefCell<T>
as well.