rustc endless loop on some constant casts

[antifuchs]

I bisected nightlies to figure out when my pull request's tests started breaking on nightly. The following is the template cargo-bisect-rustc gave me.

Regression found in the compiler

searched nightlies: from nightly-2019-10-01 to nightly-2019-12-22
regressed nightly: nightly-2019-11-20
searched commits: from 3e525e3 to 618b01f
regressed commit: d1da802
source code: antifuchs/nonzero_ext#7

Instructions

I tried the following on macOS and linux (in CI):

1. Check out the repo & branch of that pull request
2. Run cargo +nightly test --test=compiletest with a nightly version later than d1da802, that is >= nightly-2019-11-20

Error

The compile test (provided by trybuild) does not terminate - rustc seems to be running forever, consuming 99% of my CPU all the while.

Since the instructions to repro are a bit convoluted (and massive), I'll try and boil down the repro case a little bit.

[antifuchs]

Here's a playground link that better illustrates the failure. It builds with stable, but loops endlessly on nightly: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=eb03f3a6297979be89be032bbb558d38

[antifuchs]

(Never mind that the code is wrong: casting a negative number to usize is pretty messed up and seems to work only by chance; however, having the compiler endless-loop is suboptimal) (:

[antifuchs]

Reduced further to https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=1ca768b40e5cb223899e540c4c5dab4a (:

[oli-obk]

similar "endless" loop: #63952

The problem here is that you have an overflow essentially giving you let _ = [(); usize::max_value()];, which... const prop will then try to turn into a constant

cc @wesleywiser

[oli-obk]

for arrays of zsts we can solve this, but if you used u8 we'd actually need to allocate and do some operations. Maybe we should make mir building for repeat expressions not have its own Rvalue variant but instead just convert [X; N] to MIR of the following form

let mut x = MaybeUninit::<[T; N]>::uninit();
for i in &mut x {
    *x = X;
}
let x = x.assert_initialized();

[wesleywiser]

I thought this might have been fixed by #66394, but because it's a ZST, it doesn't trigger that logic. It would probably be easy to extend that logic to include large arrays of ZSTs.

[oli-obk]

While we could fix this just for const prop, we'd still have the same problem in const eval, so we should consider a general solution.

[RalfJung]

Maybe we should make mir building for repeat expressions not have its own Rvalue variant but instead just convert [X; N] to MIR of the following form

That would solve tons of problems I think. Having a single MIR statement turn into a loop in the interpreter is pretty suboptimal anyway -- usually every statement should have a fixed upper bound on its execution time.

As an interim solution we could probably skip this part for arrays of ZST.