Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
thepowersgang opened this issue Apr 20, 2020 · 5 comments · Fixed by #71488
Closed
Assignees
Labels
C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@thepowersgang
Copy link
Contributor

thepowersgang commented Apr 20, 2020

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
@thepowersgang thepowersgang added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 20, 2020
@jonas-schievink jonas-schievink added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc I-prioritize Issue: Indicates that prioritization has been requested for this issue. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Apr 20, 2020
@LeSeulArtichaut
Copy link
Contributor

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

@LeSeulArtichaut LeSeulArtichaut removed the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label Apr 20, 2020
@spastorino
Copy link
Member

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

@spastorino spastorino added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Apr 21, 2020
@rust-lang-glacier-bot rust-lang-glacier-bot added the glacier ICE tracked in rust-lang/glacier. label Apr 22, 2020
@pnkfelix
Copy link
Member

@rustbot assign @eddyb

thepowersgang added a commit to thepowersgang/rust_os that referenced this issue Apr 23, 2020
@eddyb
Copy link
Member

eddyb commented Apr 23, 2020

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
Copy link
Contributor

oli-obk commented Apr 24, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants