broken MIR NoSolution sized array initialiser with addition in generic tuple destructure

[thepowersgang]

According to my CI this started 2020-04-16 (https://travis-ci.org/github/thepowersgang/rust_os/builds/675740673) - nightly-x86_64-unknown-linux-gnu installed - rustc 1.44.0-nightly (d2230290f 2020-04-15)

Code

fn main() {}
// NOTE: Lifetime param needed.
struct DirEnts<'a>
{
    _cluster: ::std::marker::PhantomData<&'a ()>,
}
impl<'a> DirEnts<'a>
{
    #[allow(dead_code)]
    fn next(&mut self) -> [u8; 12] {
        // NOTE: Tuple destructure needed
        // NOTE: Arithmatic needed
        let (outname,) = ([0u8; 12+0],);
        outname
    }
}

Meta

rustc --version --verbose:

rustc 1.44.0-nightly (52fa23add 2020-04-18)
binary: rustc
commit-hash: 52fa23add6fb0776b32cc591ac928618391bdf41
commit-date: 2020-04-18
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0

Error output

[No write since last change]
error: internal compiler error: broken MIR in DefId(0:9 ~ 1[317d]::{{impl}}[0]::next[0]) ((_3.0: [u8; 12])): bad field access ([u8; _]: [u8; 12]): NoSolution
  --> /home/tpg/1.rs:15:8
   |
15 |         let (outname,) = ([0u8; 12+0],);
   |              ^^^^^^^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:515
  12: std::panicking::begin_panic
  13: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop
  14: core::ptr::drop_in_place
  15: <alloc::rc::Rc<T> as core::ops::drop::Drop>::drop
  16: core::ptr::drop_in_place
  17: rustc_interface::interface::run_compiler_in_existing_thread_pool
  18: scoped_tls::ScopedKey<T>::set
  19: rustc_ast::attr::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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 (52fa23add 2020-04-18) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack

shell returned 101

[LeSeulArtichaut]

cargo-bisect-rustc reports a regression in d12f030 (PR #70452), cc @eddyb

searched nightlies: from nightly-2020-04-15 to nightly-2020-04-16
regressed nightly: nightly-2020-04-16
searched commits: from https://github.com/rust-lang/rust/commit/edc02580e4e80476ac1ded2cc1008eaf8b8400e6 to https://github.com/rust-lang/rust/commit/d2230290f7220e740ec08f4d844bf5951e1b74b8
regressed commit: https://github.com/rust-lang/rust/commit/d12f0304839e599d498b3faaa652336b273bdcc8

[spastorino]

Assigning P-high as discussed as part of the Prioritization Working Group process and removing I-prioritize.

[pnkfelix]

@rustbot assign @eddyb

[eddyb]

Oh dear, I was hoping crater will find all such issues (this is #70773). I guess nobody in the wild is pattern-matching tuples with non-literal-length arrays.

I can repro by adding this line (playground) to the #70773 test (and the PR fixing this should IMO add the line to src/test/ui/consts/issue-70773-mir-typeck-lt-norm.rs):

let (_array,) = ([0; HASH_LEN],);

The fix is likely trivial: add another normalization, like in 8989029.
Presumably, for field accesses, this time (weird that .0 doesn't trigger the bug).

---

I've brought it up before w/ @oli-obk (but I don't know if I've seen a response), that the lack of normalization for array lengths in typeck is pushing complexity to the rest of the compiler and maybe we should do it in typeck. But then again, Lazy Normalization Is Coming™, so maybe there's no point.

[oli-obk]

I believe I responded in the PR where you already asked me about that. I'm fine reintroducing a normalization phase