heisenbug: debug builds `Integer::repr_discr` has transient ICE on `compile-fail/enum-discrim-too-small2.rs`

[pnkfelix]

My config.toml:

[rust]
codegen-units = 8
debug = true
optimize = true
debug-assertions = true
debuginfo = true
debuginfo-lines = true

And my (odd?) build invocation:

% time python /Users/fklock/Dev/Mozilla/rust-mirborrowck/.git/../x.py test src/tools/tidy && \
  time python /Users/fklock/Dev/Mozilla/rust-mirborrowck/.git/../x.py build --stage 1 --incremental --keep-stage 0 src/libstd && \
  time python /Users/fklock/Dev/Mozilla/rust-mirborrowck/.git/../x.py test --stage 1 src/test/{mir-opt,compile-fail,run-pass}

Results in stage 1 binary where we get weirdness on this compile-fail test:

% ./objdir-dbgopt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/compile-fail/enum-discrim-too-small2.rs
error: literal out of range for i8
  --> src/test/compile-fail/enum-discrim-too-small2.rs:18:11
   |
18 |     Ci8 = 223, //~ ERROR literal out of range for i8
   |           ^^^
   |
note: lint level defined here
  --> src/test/compile-fail/enum-discrim-too-small2.rs:11:9
   |
11 | #![deny(overflowing_literals)]
   |         ^^^^^^^^^^^^^^^^^^^^

error: literal out of range for i16
  --> src/test/compile-fail/enum-discrim-too-small2.rs:25:12
   |
25 |     Ci16 = 55555, //~ ERROR literal out of range for i16
   |            ^^^^^

error: literal out of range for i32
  --> src/test/compile-fail/enum-discrim-too-small2.rs:32:12
   |
32 |     Ci32 = 3_000_000_000, //~ ERROR literal out of range for i32
   |            ^^^^^^^^^^^^^

error: internal compiler error: librustc/ty/layout.rs:553: Integer::repr_discr: `#[repr]` hint too small for discriminant range of enum `Ei64

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.25.0-dev running on x86_64-unknown-linux-gnu

thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:508:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I am pretty sure this is specific to debug builds. At least, that's my current best guess as to why this hasn't been caught by bors.

The code layout.rs looks like this:

       if let Some(ity) = repr.int {
            let discr = Integer::from_attr(tcx, ity);
            let fit = if ity.is_signed() { signed_fit } else { unsigned_fit };
            if discr < fit {
                bug!("Integer::repr_discr: `#[repr]` hint too small for \
                  discriminant range of enum `{}", ty)
            }
            return (discr, ity.is_signed());
        }

it should probably be signalling a proper error, or trusting that the lint will eventually fire and catch this, rather than just triggering a call to bug! (since this does not represent a bug in the compiler itself, right?)

[pnkfelix]

(It seems easy enough to add another LayoutError variant and returning that from Integer::repr_discr. Trying a build with that change now.)

[pnkfelix]

Hmm. Apparently we have run-pass test that is relying on Integer::repr_discr call not erroring! Investigating...

[pnkfelix]

(I am now suspecting that there is a Layout bug lurking here...)

[pnkfelix]

FYI the test in question is https://github.com/rust-lang/rust/blob/master/src/test/run-pass/discrim-explicit-23030.rs

I'm double checking what's going on in the layout code now, to see if its something obviously wrong with the these explicitly assigned values...

[pnkfelix]

Update: Something might have been terribly wrong with my builds. Things went south in other very strange ways while I was working on this.

[pnkfelix]

Yes, as far as I can tell, at least some of the problems I was observing seem to have gone away after x.py clean ... :(

Closing this ticket.

[pnkfelix]

(while I am not yet willing to reopen this ticket, I am seeing this same scenario arise on two different computers, which makes me think that while it may be some transient issue, its something we still may need to look more carefully into. But whatever's going on, the fact that it does not consistently reproduce is sign of a deeper problem than what this bug description indicates...)

Update: to be clear: It consistently reproduces for some compiler builds. That is, I can re-run the test over and over and see it. The problem is that small unrelated changes to the rustc source (e.g. sometimes just adding debug! calls, or expanding an existing one) can cause the problem to go away, and (AFAICT) it is not trivial to bring the problem back.

[pnkfelix]

... just saw it arise again (on a build that I am pretty sure was working a little while ago...). For the record, on my Linux box, this is the command line I am invoking for each build:

../x.py test src/tools/tidy && ../x.py build --incremental --keep-stage 0 --stage 1 src/libstd && ../x.py test --stage 1 src/test/{mir-opt,compile-fail,run-pass}

I am becoming tempted to start digging into why this keeps cropping up for me...

[pnkfelix]

For the record, I am seeing cases where (presumably inlined) calls to Integer::fit_signed are returning the wrong value for edge cases.

That is, after instrumenting the panic message with more data, I get a message that min: -9223372036854775808 ends up being mapped to I128 by the aforementioned function.

And that should not be happening. (That is, it is presumably some sort of code generation bug.)

[pnkfelix]

Reopening ticket. I'm seeing this on a build on my mac (it can crop up on either linux or mac) so I'm going to spend some time digging into the generated machine code and try to get to the bottom of what's going on.