-
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
Allow assignments in const contexts #56070
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
r? @RalfJung |
This comment has been minimized.
This comment has been minimized.
r=me with tidy happy:
|
@bors r=RalfJung |
📌 Commit 37fcd5c has been approved by |
Place::Local(index) => break *index, | ||
// projections are transparent for assignments | ||
// we qualify the entire destination at once, even if just a field would have | ||
// stricter qualification |
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 doesn't seem correct - if you assign something with less qualifications to a field of a value with more, you turn those bits off.
In the future, please cc me on @bors r- |
// projections are transparent for assignments | ||
// we qualify the entire destination at once, even if just a field would have | ||
// stricter qualification | ||
Place::Projection(proj) => dest = &proj.base, |
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.
Continuing with
the mindset when dealing with [const qualif] should be "how do I break this?"
Projections would include Deref
, which isn't a problem because we can't have mutable references at all inside const contexts. Still something to think about.
Downcast
also can't happen, because we'd need match
for that.
Maybe we should just whitelist field projections for now.
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.
The problem is something like this:
const FOO: &(Cell<usize>, bool) = &{
let mut foo = (Cell::new(0), false);
foo.1 = true; // resets `qualif(foo)` to `qualif(true)`
foo
};
I suspect that will actually compile with this PR, although I'd like a confirmation.
We could add this as a testcase, but you might be able to come up with something simpler/more general.
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 indeed compiles successfully with this PR
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.
My suggestion is field (or projections in general) assignment should combine qualifications (i.e. |=
) instead of replacing them.
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 now reuse the existing projection checks for reading values. These checks replace the qualification with NOT_CONST
, so there's no real use in combining I think?
I'll happily hand them over to you. ;) r? @eddyb |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors r=eddyb |
📌 Commit 6db8c6c has been approved by |
☀️ Test successful - status-appveyor, status-travis |
fixes #54098
fixes #51251
fixes #52613