-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Const qualification comments #61492
Const qualification comments #61492
Conversation
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
r? @eddyb |
// Constant containing interior mutability (UnsafeCell). | ||
/// Constant containing interior mutability (UnsafeCell). | ||
/// This must be ruled out to make sure that evaluating the constant at compile-time | ||
/// and run-time would produce the same result. |
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.
Nope, that's irrelevant. The problem is promoting e.g. &AtomicUsize
and then mutating it.
That is, uses of the promoted references must not be able to distinguish between the promoted and unpromoted case (ignoring pointer addresses).
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.
Well that's what I meant.^^
And also the part where any use of a const
item must be equivalent to inlining its definition.
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 have expanded the description a bit, is this better?
/// for value qualifications, and accumulates writes of | ||
/// rvalue/call results to locals, in `local_qualif`. | ||
/// For functions (constant or not), it also records | ||
/// candidates for promotion in `promotion_candidates`. |
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 just functions though, I think for everything? Promotion still has to do something in const
/static
, it's just slightly different than at runtime.
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.
No idea, I just moved that comment up, I did not write it.^^
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.
There's a comment in the file though saying
// No need to do anything in constants and statics, as everything is "constant" anyway
// so promotion would be useless.
if self.mode != Mode::Static && self.mode != Mode::Const {
So it does seem to not do promotion the same way for statics and consts?
@@ -757,6 +788,9 @@ impl<'a, 'tcx> Checker<'a, 'tcx> { | |||
// `let _: &'static _ = &(Cell::new(1), 2).1;` | |||
let mut local_qualifs = self.qualifs_in_local(local); | |||
local_qualifs[HasMutInterior] = false; | |||
// Make sure there is no reason to prevent promotion. | |||
// This is, in particular, the "implicit promotion" version of | |||
// the check making sure that we don't run drop glue during const-eval. |
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 seems oddly specific - this is the original sole check, so comparing it to something newer seems off.
You could move the comment one line above and make it more about "any qualifications, except HasMutInterior
(see above), disqualify from promotion".
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 don't think which check came first historically has any bearing here. Just because it grew that way doesn't mean that's the best way to explain it.
The other check is IMO clearly "more principled" by looking at the place where the side-effect actually occurs.
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 have adjusted the wording a bit.
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.
Some proof-reading :)
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #61548) made this pull request unmergeable. Please resolve the merge conflicts. |
6bb0760
to
dfa40d3
Compare
☔ The latest upstream changes (presumably #61653) made this pull request unmergeable. Please resolve the merge conflicts. |
96436e3
to
38c7f3e
Compare
This is bitrotting. @eddyb could you have a look at my edits? |
@bors r+ |
📌 Commit 38c7f3e has been approved by |
☔ The latest upstream changes (presumably #61506) made this pull request unmergeable. Please resolve the merge conflicts. |
38c7f3e
to
0edf46f
Compare
Rebased. @bors r=eddyb |
📌 Commit 0edf46f has been approved by |
⌛ Testing commit 0edf46f with merge 0efa0a6a57bfe2ed3e05e02850f3c18d8747b767... |
💥 Test timed out |
@bors retry |
☀️ Test successful - checks-travis, status-appveyor |
I extracted some const-qualif knowledge from @eddyb. This is my attempt to turn that into comments.
Cc @oli-obk @eddyb