-
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
Unconditionally breaking loop
s not allowed in constants.
#62272
Labels
A-const-eval
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
A-MIR
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
Comments
eddyb
added
A-MIR
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
A-const-eval
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
labels
Jul 1, 2019
This was referenced Jul 1, 2019
I think this is a technicality and that we can continue to let this be broken since no one said a peep about it since 1.25. The upside is that the syntactic surface of const eval is clearer. |
On the PR I explained why I think we should fix this even if we want to ban loops: #62274 (comment) |
Centril
added a commit
to Centril/rust
that referenced
this issue
Jul 12, 2019
rustc_mir: follow FalseUnwind's real_target edge in qualify_consts. As far as I can tell, this was accidentally omitted from rust-lang#47802. Fixes rust-lang#62272. r? @matthewjasper or @nikomatsakis
ecstatic-morse
added a commit
to ecstatic-morse/rust
that referenced
this issue
Nov 9, 2019
This PR BREAKS CODE THAT WAS ACCEPTED ON STABLE. It's arguably a bug that this was accepted in the first place, but here we are. See rust-lang#62272 for more info.
bors
added a commit
that referenced
this issue
Nov 11, 2019
Add a HIR pass to check consts for `if`, `loop`, etc. Resolves #66125. This PR adds a HIR pass to check for high-level control flow constructs that are forbidden in a const-context. The MIR const-checker is unable to provide good spans for these since they are lowered to control flow primitives (e.g., `Goto` and `SwitchInt`), and these often don't map back to the underlying statement as a whole. This PR is intended only to improve diagnostics once `if` and `match` become commonplace in constants (behind a feature flag). The MIR const-checker will continue to operate unchanged, and will catch anything this check might miss. In this implementation, the HIR const-checking pass is run much earlier than the MIR one, so it will supersede any errors from the latter. I will need some mentoring if we wish to change this, since I'm not familiar with the diagnostics system. Moving this pass into the same phase as the MIR const-checker could also help keep backwards compatibility for items like `const _: () = loop { break; };`, which are currently (erroneously?) accepted by the MIR const-checker (see #62272). r? @Centril cc @eddyb (since they filed #62272)
ecstatic-morse
added a commit
to ecstatic-morse/rust
that referenced
this issue
Nov 13, 2019
This PR BREAKS CODE THAT WAS ACCEPTED ON STABLE. It's arguably a bug that this was accepted in the first place, but here we are. See rust-lang#62272 for more info.
bors
added a commit
that referenced
this issue
Nov 13, 2019
Add a HIR pass to check consts for `if`, `loop`, etc. Resolves #66125. This PR adds a HIR pass to check for high-level control flow constructs that are forbidden in a const-context. The MIR const-checker is unable to provide good spans for these since they are lowered to control flow primitives (e.g., `Goto` and `SwitchInt`), and these often don't map back to the underlying statement as a whole. This PR is intended only to improve diagnostics once `if` and `match` become commonplace in constants (behind a feature flag). The MIR const-checker will continue to operate unchanged, and will catch anything this check might miss. In this implementation, the HIR const-checking pass is run much earlier than the MIR one, so it will supersede any errors from the latter. I will need some mentoring if we wish to change this, since I'm not familiar with the diagnostics system. Moving this pass into the same phase as the MIR const-checker could also help keep backwards compatibility for items like `const _: () = loop { break; };`, which are currently (erroneously?) accepted by the MIR const-checker (see #62272). r? @Centril cc @eddyb (since they filed #62272)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-const-eval
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
A-MIR
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
Technically a regression from 1.24 to 1.25, but I don't think anyone used this.
Example code which used to be allowed:
I'm pretty sure this changed with #47802, which added the
FalseUnwind
terminator to MIR, but didn't handle it in const-checking (which otherwise ignores cleanup blocks).cc @matthewjasper @nikomatsakis
The text was updated successfully, but these errors were encountered: