Repository navigation
[trait constants] thread 'rustc' panicked at 'assertion failed: (left == right) ...' #70942
Description
I'm seeing an internal compiler error on the following input (found by fuzz-rustc):
trait Nat {
const VALUE: usize;
}
struct Zero;
impl Nat for Zero {
const VALUE: i32 = 0;
}
fn main() {
let _: [i32; Zero::VALUE] = [];
}$ rustc main.rs
error[E0326]: implemented const `VALUE` has an incompatible type for trait
--> main.rs:8:18
|
2 | const VALUE: usize;
| ----- type in trait
...
8 | const VALUE: i32 = 0;
| ^^^ expected `usize`, found `i32`
thread 'rustc' panicked at 'assertion failed: `(left == right)`
left: `8`,
right: `4`', /rustc/485c5fb6e1bf12cd11a8fac5ee94962e17cff74b/src/libstd/macros.rs:16:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.44.0-nightly (485c5fb6e 2020-04-08) running on x86_64-unknown-linux-gnu
error: aborting due to previous error
For more information about this error, try `rustc --explain E0326`.
Activity
dwrensha commentedon Apr 9, 2020
The ICE seems to have been introduced at some point between
rustcversions 1.35 and 1.36.Phosphorus15 commentedon Apr 9, 2020
Seems like something went wrong with const eval
Centril commentedon Apr 9, 2020
cc @oli-obk @RalfJung
RalfJung commentedon Apr 9, 2020
Opsie, that ICE is a safety net that protects us against using constant values at the wrong type (and accidentally transmuting them). Looks like something here isn't aware that there was a type error and goes on using the wrong type for the wrong data.
RalfJung commentedon Apr 9, 2020
@dwrensha do you have a backtrace with line numbers?
Curiously, on stable the ICE message is different:
RalfJung commentedon Apr 9, 2020
So this looks like something is actually running Miri on this ill-typed code, and then doing a MIR assignment where source and target do not have the same size. Since array lengths are involved, I suspect this is similar to
rust/src/librustc_mir/interpret/place.rs
Lines 932 to 943 in 11f6096
I wonder if there is some way we can not run Miri on MIR like this that is broken beyond repair, to avoid accumulating such hacks?
Centril commentedon Apr 9, 2020
With line numbers:
Details
steffahn commentedon Apr 9, 2020
Bisection points to 45bbd14 (#60126).
3 remaining items
RalfJung commentedon Apr 9, 2020
Hm, however, looking at @Centril's stack trace above, I do quite wonder how we are getting past the
mir_assign_valid_typescheck. That one should not let types with different size pass through. We recently changed that check, which explains the nightly vs. stable difference, but this is an unexpected consequence of this change. Cc @eddybeddyb commentedon Apr 9, 2020
Thanks for pinging me, I believe I've already fixed this in a PR of mine, I should've submitted as a separate PR. Will do that now, assuming it fixes this issue.For the record, said commit is the first commit in #70452 (currently 7c0257f), titled"typeck: track any errors injected during writeback and taint tables appropriately.".
EDIT: ugh, it doesn't because the body that should've been tainted-by-errors is the associated
constin theimplwhich doesn't know it has the wrong type (because the error is a separate check).steffahn commentedon Apr 9, 2020
More precisely, the error message changes to (pretty much) the current one in #69181.
RalfJung commentedon Apr 9, 2020
@steffahn thanks, that makes a lot of sense.
Turns out the types on both sides are fine. It's just that the value returned by
eval_operanddoes not match the type (we are getting a 32bit-value at typeusize). So the type check is fine but the value sanity check later ICEs. Just like I was worried in #69181, that PR broke layer one of our safety net by throwing away some layout information; this ICE was triggered by layer two.^^EDIT: Okay what I was worried about was actually the other call site changed in that PR.
eddyb commentedon Apr 10, 2020
Fix is up at #70970.
LeSeulArtichaut commentedon Apr 10, 2020
This is a test
@rustbot prioritize
rustbot commentedon Apr 10, 2020
Error: This issue has already been requested for prioritization.
Please let
@rust-lang/releaseknow if you're having trouble with this bot.Rollup merge of rust-lang#70970 - eddyb:trait-vs-impl-mismatch, r=oli…