Closed matthiaskrgr closed 6 months ago
Seems like a duplicate of https://github.com/rust-lang/miri/issues/2608 -- we should just stop after that error message and not go on interpreting.
It's actually a different issue, as this error occurs during interpretation, not before, so we need to check on every step (or properly bubble out this error to the interpreter)
We already propagate layout errors though, shouldn't that subsume this case?
@matthiaskrgr I can't see the actual ICE message in the output above, is there some other output that you cut from the issue?
We already propagate layout errors though, shouldn't that subsume this case?
This is a cycle error, which emits an error and then should abort, but somehow miri subverts this abort. I am investigating how to bubble up the "a cycle occurred" from the layout error
somehow miri subverts this abort
Oh I see. Might be worth figuring out how to avoid this (as an alternative to fundamentally changing the cycle error treatment).
If we want to generally avoid miri reporting fatal errors as ICEs, we need to stop catching unwinding of a Fatal
error. I don't know if this is generally doable, but we could match on the panic message in the worst case.
Alternatively we can wait for more reports and look into removing those fatal errors
Yeah I didn't realize that there are cases where rustc is expected to unwind.
Using a different unwinding payload type for ICEs vs regular fatal errors is not an option, or is it?
Using a different unwinding payload type for ICEs vs regular fatal errors is not an option, or is it?
I think that already happens but I am not sure. I will investigate. But that's kinda what I mean. Even if it is possible, do we want to?
Looks like we use FatalError
for fatal errors and ExplicitBug
or DelayedBugPanic
for ICE.
If we can check the payload type before printing the Miri ICE message, that seems like a clean solution?
This now prints a much nicer error, without an ICE:
error[E0391]: cycle detected when computing layout of `S<S<()>>`
|
= note: ...which requires computing layout of `<S<()> as Tr>::I`...
= note: ...which again requires computing layout of `S<S<()>>`, completing the cycle
= note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information
error: post-monomorphization error: a cycle occurred during layout computation
--> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:313:5
|
313 | intrinsics::size_of::<T>()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ a cycle occurred during layout computation
|
= note: BACKTRACE:
= note: inside `std::mem::size_of::<S<S<()>>>` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:313:5: 313:31
note: inside `foo::<S<()>>`
--> src/main.rs:20:5
|
20 | mem::size_of::<S<T>>()
| ^^^^^^^^^^^^^^^^^^^^^^
note: inside `main`
--> src/main.rs:24:20
|
24 | println!("{}", foo::<S<()>>());
| ^^^^^^^^^^^^^^
Should miri be able to bail out more gracefully in this scenario?
rustc:
miri: