-
Notifications
You must be signed in to change notification settings - Fork 531
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
isolate non-mut static part from static-item section #760
base: master
Are you sure you want to change the base?
Conversation
that is not [interior mutable] may be placed in read-only memory. Static items | ||
do not call [`drop`] at the end of the program. |
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.
This looks like it could use some more re-arranging. The sentence about drop
should probably be moved up since it applies to both mut and non-mut, correct?
All access to a Non-`mut` static is safe, but there are a number of restrictions on | ||
Non-`mut` statics: |
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.
Not all these rules seem to apply to non-mut
static. In fact, maybe only the first one?
Also, this sentence (the original) seems to be a very strong assertion (all access?). I'm not up to speed on safety issues, so maybe @Centril could validate what should be safe, or if this wording makes sense.
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.
Yeah this diff seems to remove rules about static mut
like the thing about referring to constants.
cc @RalfJung and @eddyb on the access thing, but notably, a static
in an extern
block is not safe to access and requires an unsafe
context (https://doc.rust-lang.org/nightly/reference/items/external-blocks.html#statics). However, some static
take be part of some internal contract that makes it unsound to access under some circumstances, even if the language rules do not enforce it. Under that reading it seems to me that the current wording makes sense.
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 mean you can access a non-mut
static in safe code, so as a matter of fact this statement is correct, or at least some interpretation of it. ;) However, as a reflection of what the compiler is doing, extern
statics should probably be excluded somewhere.
"all access" is slightly misleading though; writing to a static X: i32
is not safe and thus rejected by the compiler.
(This might also be a good place to call out that mutating a non-mut
non-interior-mut extern static X: T
is UB, even if that mutation happens by non-Rust code.)
that is not [interior mutable] may be placed in read-only memory. Static items | ||
do not call [`drop`] at the end of the program. | ||
|
||
All access to a static is safe, but there are a number of restrictions on | ||
statics: | ||
All access to a Non-`mut` static is safe, but there are a number of restrictions on |
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.
All access to a Non-`mut` static is safe, but there are a number of restrictions on | |
All access to a non-`mut` static is safe, but there are a number of restrictions on |
All access to a static is safe, but there are a number of restrictions on | ||
statics: | ||
All access to a Non-`mut` static is safe, but there are a number of restrictions on | ||
Non-`mut` statics: |
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.
Non-`mut` statics: | |
non-`mut` statics: |
☔ The latest upstream changes (possibly bf115a4) made this pull request unmergeable. Please resolve the merge conflicts. |
No description provided.