-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Fix various aspects around let
bindings inside const functions
#56160
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
Additionally, here's a comprehensive run-pass test that would be nice to add: https://gist.github.com/Centril/a8df54dc8ee0b6bf0da46b5fba446acd
This comment has been minimized.
This comment has been minimized.
@oli-obk Can we poison the MIR (i.e. add a flag that we set to |
@oli-obk I remembered one thing now... floating points and assignment ops... we should make sure that they are not stabilized by including a test with all of the assignment ops for f32 & f64. :) |
Having reviewed the main tests, I pass on the torch to... also cc @RalfJung and @nikomatsakis |
@oli-obk Can you add tests for |
I had the exact same idea like an hour ago. I guess that means it wasn't a stupid idea |
I'm going to reintroduce the feature gate and let the final version bake a little more in nightly. I don't feel comfortable changing so many things and stabilizing at the same time. |
Single match arms lead to |
@oli-obk Maybe because of the |
Nit all single-arm matches should work, IMO. Just things like |
e518293
to
e07242f
Compare
This comment has been minimized.
This comment has been minimized.
9b8ecfb
to
afe9e6e
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
let
bindings inside const functionslet
bindings inside const functions
@@ -320,6 +320,10 @@ impl<'a, 'tcx> Qualifier<'a, 'tcx, 'tcx> { | |||
} | |||
} | |||
|
|||
fn const_let_allowed(&self) -> bool { |
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.
Seems like a great place for a comment =) in particular, documenting the logic behind these rules.
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.
Something like:
Currently, without a feature gate, let
is only allowed in const fn
. With a feature gate, it can appear anywhere.
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.
We decided on not doing this dual-scheme. Instead we're poisoning constants that use short circuiting operators so they can't also have let
bindings.
I'll remove the function and move back to checking the feature gate directly
cx.control_flow_destroyed.push(( | ||
op.span, | ||
"`&&` operator".into(), | ||
)); | ||
ExprKind::Binary { |
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.
Woah. I don't think I realized we do this sort of conversion.
if context.is_mutating_use() { | ||
this.not_const() | ||
} else { | ||
this.qualif = Qualif::NOT_CONST; |
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.
Is this intentionally overriding all other Qualif
flags? (vs invoking add
)? Why is that? Maybe a comment?
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.
That is an accidental leftover from the larger refactorings. I undid the change and added comments
First round of review -- I'd like to take one more look before r+ and in particular to know the answer to this question |
@@ -0,0 +1,26 @@ | |||
error: new features like let bindings are not permitted in constant which also use short circuiting operators |
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 reads oddly, it should be "in constants" -- i.e., plural
error: new features like let bindings are not permitted in constant which also use short circuiting operators | ||
--> $DIR/const_short_circuit.rs:6:9 | ||
| | ||
LL | let mut x = true && false; |
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.
also, I presume we intend this to be temporary? this restriction is very odd and surprising from an end-user point-of-view, I wonder if we can direct people to some kind of roadmap / URL that explains what the heck is going on?
r=me modulo nits above |
@bors r=nikomatsakis |
📌 Commit d815e2b has been approved by |
⌛ Testing commit d815e2b with merge 36b0f367a017ba709a4539a6873344e7ee62e756... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Fix various aspects around `let` bindings inside const functions * forbid `let` bindings in const contexts that use short circuiting operators * harden analysis code against derefs of mutable references Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
☀️ Test successful - status-appveyor, status-travis |
let
bindings in const contexts that use short circuiting operatorsInitially this PR was about stabilizing
let
bindings, but too many flaws were exposed that need some more testing on nightly