Skip to content
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

Merged
merged 1 commit into from
May 31, 2021

Conversation

Aaron1011
Copy link
Member

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.

@rust-highfive
Copy link
Collaborator

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

@rust-highfive
Copy link
Collaborator

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 26, 2021
@davidtwco
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented May 26, 2021

📌 Commit ec0819b03e2c9e756e25a61963384101d9355485 has been approved by davidtwco

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 26, 2021
}
// 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(),
Copy link
Member

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?

Copy link
Member

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.

@RalfJung
Copy link
Member

RalfJung commented May 26, 2021

@bors r-
I left some comments.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 26, 2021
@davidtwco
Copy link
Member

r? @RalfJung

@Aaron1011
Copy link
Member Author

@RalfJung: I've refactored the code to better handle the message parameter. This makes the error message for panics slightly worse (it says 'any use of this value will cause an error', like it does on master). However, displaying a nicer message without simply ignoring message will require some additional refactoring, since the calling code is assuming that we're emitting a lint.

@Aaron1011 Aaron1011 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 30, 2021
@RalfJung
Copy link
Member

This makes the error message for panics slightly worse (it says 'any use of this value will cause an error', like it does on master). However, displaying a nicer message without simply ignoring message will require some additional refactoring, since the calling code is assuming that we're emitting a lint.

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 }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is redundant now.

@RalfJung
Copy link
Member

Looking good! Feel free to bors r=RalfJung once CI is green.
@bors delegate+

@bors
Copy link
Contributor

bors commented May 30, 2021

✌️ @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.
@Aaron1011
Copy link
Member Author

@bors r=RalfJung

@bors
Copy link
Contributor

bors commented May 30, 2021

📌 Commit 2779fc1 has been approved by RalfJung

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 30, 2021
@bors
Copy link
Contributor

bors commented May 31, 2021

⌛ Testing commit 2779fc1 with merge d84a9199537f1ccd5f8b42eed4a09e8296f45b14...

@rust-log-analyzer
Copy link
Collaborator

The job dist-x86_64-apple-alt failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
      Memory: 14 GB
      Boot ROM Version: VMW71.00V.13989454.B64.1906190538
      Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
      SMC Version (system): 2.8f0
      Serial Number (system): VM2mYAuJnmkX

hw.ncpu: 3
hw.byteorder: 1234
hw.memsize: 15032385536

@bors
Copy link
Contributor

bors commented May 31, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 31, 2021
@Aaron1011
Copy link
Member Author

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 31, 2021
@bors
Copy link
Contributor

bors commented May 31, 2021

⌛ Testing commit 2779fc1 with merge d9feaaa...

@bors
Copy link
Contributor

bors commented May 31, 2021

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing d9feaaa to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 31, 2021
@bors bors merged commit d9feaaa into rust-lang:master May 31, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 31, 2021
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #85704!

Tested on commit d9feaaa.
Direct link to PR: #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).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request May 31, 2021
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).
@lqd
Copy link
Member

lqd commented Jun 1, 2021

For people trying to understand the rationale of this change, see #85194 where the decision was made for turning the lint into a hard error. And since this forward-incompatibility lint was tracked in #71800, that issue should probably be closed.

@RalfJung
Copy link
Member

RalfJung commented Jun 1, 2021

#71800 tracks making all CTFE errors hard errors.
This here does it just for panics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants