-
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
Add a forever unstable opt-out of const qualification checks #56123
Conversation
This comment has been minimized.
This comment has been minimized.
cc @rust-lang/compiler |
--> $DIR/assoc_const_2.rs:27:13 | ||
| | ||
LL | let y = <String as Bar<String>>::F; //~ ERROR erroneous constant | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors |
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.
"Has errors" is not very precise, why does it not show an actual miri error?
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.
because of allow(const_err)
silencing the lint that reports the error on a constant
src/libsyntax/feature_gate.rs
Outdated
@@ -230,6 +230,11 @@ declare_features! ( | |||
// Allows panicking during const eval (produces compile-time errors) | |||
(active, const_panic, "1.30.0", Some(51999), None), | |||
|
|||
// Don't run any static analyses on constants and `const fn` and just "let miri handle it" | |||
// NOT meant to ever be stabilized, this is solely for being able to demonstrate problems with | |||
// features of alternative RFCs when writing RFCs that would allow more const features. |
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 sounds useful for test cases.
Would it be reasonable to add this as a |
I'm not particularly bound to using features. Do we have any other |
I'd count these:
|
@varkor The main nice thing about features is that it becomes easy to test stuff out in the playground and such so if it's not too much of a problem using features would be nice. |
TBH I also feel like a |
NB: |
Discussed in compiler meeting. A flag is definitely better because
|
This was discussed a week ago in T-compiler. Reviewing the discussion now, it seems like there was consensus that the feature should be a Un-nominating. |
0377cc4
to
051fcd9
Compare
This comment has been minimized.
This comment has been minimized.
051fcd9
to
2e102ca
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
bfea651
to
2747960
Compare
This comment has been minimized.
This comment has been minimized.
2747960
to
8a949a3
Compare
☔ The latest upstream changes (presumably #57542) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping from triage! What is the status of this PR? |
8a949a3
to
d0129a6
Compare
@bors r+ |
📌 Commit d0129a6 has been approved by |
@bors r=eddyb the bors queue did not pick this up as "approved" |
📌 Commit d0129a6 has been approved by |
Add a forever unstable opt-out of const qualification checks r? @eddyb cc @RalfJung @Centril basically a forever unstable way to screw with const things in horribly unsafe, unsound and incoherent ways. Note that this does *not* affect miri except by maybe violating assumptions that miri makes. But there's no change in how miri evaluates things.
☀️ Test successful - checks-travis, status-appveyor |
r? @eddyb
cc @RalfJung @Centril
basically a forever unstable way to screw with const things in horribly unsafe, unsound and incoherent ways.
Note that this does not affect miri except by maybe violating assumptions that miri makes. But there's no change in how miri evaluates things.