-
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
UnsafeCell semantics #16022
Comments
At this point, |
rust-lang/rfcs#1447 - rfc discussing aliasing. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 11, 2023
…m-macros, r=lnicola internal: Don't explicitly warn against `semicolon_in_expressions_from_macros` This has been warn-by-default for two years now and has already been added to the future-incompat lints in 1.68. See rust-lang#79813 for the tracking issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed that we currently emit
noalias
on function parameters of type&mut
unconditionally, even if they containUnsafeCell
. This means that we cannot create aliases to the data ofUnsafeCell
if we pass it to a function as&mut
, which implies that we cannot create aliases to mutable data at all. This seems to go against the spirit and documentation ofUnsafeCell
. @cmr indicated on IRC that this might be reasonable, sinceUnsafeCell
is supposedly only used with&
. I think it's a bit odd that changing from&
to&mut
will silently breakUnsafeCell
usage.I suggest we allow
UnsafeCell
to work with&mut
. I further suggest that we only allow pointers based on (using LLVM's definition)UnsafeCell::get
andUnsafeCell::unwrap
. This means we can ensure the implementation ofUnsafeCell::get
doesn't base it's return on&self
and then mark all references asnoalias
.I'm not sure if that will lead to performance improvements since it will inhibit alias analysis on the unsafe code. An expensive way to fix that would be to remove all non-conservative
noalias
markers, letUnsafeCell::get
's return be based on&self
and run LLVM passes again.The text was updated successfully, but these errors were encountered: