-
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
Emit a hard error when a panic occurs during const-eval #85704
Conversation
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
@bors r+ |
📌 Commit ec0819b03e2c9e756e25a61963384101d9355485 has been approved by |
} | ||
// We must *always* hard error on these, even if the caller wants just a lint. | ||
err_inval!(Layout(LayoutError::SizeOverflow(_))) => true, | ||
InterpError::MachineStop(err) => err.is_hard_err(), |
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 this is right. Check the comment below where must_error
is used:
if must_error {
// The `message` makes little sense here, this is a more serious error than the
// caller thinks anyway.
// See <https://github.com/rust-lang/rust/pull/63152>.
We are now entering that code path for panics, aren't we?
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 guess ignoring the message
works out in this case... but the comment is still wrong or at least misleading now.
@bors r- |
r? @RalfJung |
ec0819b
to
58deca2
Compare
@RalfJung: I've refactored the code to better handle the |
I think if we want to use a different "lint title" (the thing displayed on the first line, no idea what its proper name is), then we should do so consistently for all errors, not just for panics. So, I agree with this. Some people argued that the title should already say what kind of error we have -- I am not opposed, I just think this should be done for panics and other CTFE errors alike. Also that entire code should probably be refactored, it does some wacky things and I have no idea why, and haven't yet dared touch this code. |
@@ -55,7 +55,9 @@ macro_rules! throw_machine_stop_str { | |||
write!(f, $($tt)*) | |||
} | |||
} | |||
impl rustc_middle::mir::interpret::MachineStopType for Zst {} | |||
impl rustc_middle::mir::interpret::MachineStopType for Zst { | |||
fn is_hard_err(&self) -> bool { 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.
This is redundant now.
Looking good! Feel free to |
✌️ @Aaron1011 can now approve this pull request |
Previous, a panic during const evaluation would go through the `const_err` lint. This PR ensures that such a panic always causes compilation to fail.
d5e94c5
to
2779fc1
Compare
@bors r=RalfJung |
📌 Commit 2779fc1 has been approved by |
⌛ Testing commit 2779fc1 with merge d84a9199537f1ccd5f8b42eed4a09e8296f45b14... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@d9feaaa. Direct link to PR: <rust-lang/rust#85704> 💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
#71800 tracks making all CTFE errors hard errors. |
Previous, a panic during const evaluation would go through the
const_err
lint. This PR ensures that such a panic always causescompilation to fail.