Repository navigation
ICE when compiling nalgebra 0.25.4 in Release mode #100550
Description
Activity
- addedC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
on Aug 14, 2022 cc @cjgillot this seems like those mir-inliner bugs 🤔
Saw a couple of these in Crater, though typically with some other ICEs too (which is why I didn't file bugs). But tagging as 1.64 and beta regression.
- addedregression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
on Aug 14, 2022 - addedI-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}Issue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
on Aug 14, 2022 Indeed, that's the "usual" normalization failure ICE we have with the MIR inliner.
When enabling the MIR inliner, I only added a check that we don't have such type mismatch at the signature, but I did not attempt to check all types that appear in the MIR for such mismatch.
If we want to fully avoid this ICE, we'd need to fully visit the callee body to check for those type mismatches.@compiler-errors do you know if progress has been made on the normalization front?
Hmm, maybe this is fixed by #100121, but I don't have time to investigate this right now.
Edit: It's not fixed.
@cjgillot Do you think it may make sense to disable the MIR inliner on beta to give it some more time to bake? I think it was switched on mid-cycle in 1.64, right?
@Mark-Simulacrum I qualify this as a bug in type normalization that MIR validation exposes. It's not a bug in the MIR inliner.
There are 3 ways to address this:
- add more exceptions to the MIR inliner to avoid those bugs (easy but cumbersome, Check projection types before inlining MIR #100571);
- fix type normalization (very hard);
- relax MIR validation (tentative in Try normalizing types without RevealAll in ParamEnv in MIR validation #100121);
- stop validating MIR in released compilers but keep doing it on tests (very easy).
However, I don't think that disabling the MIR inliner will help.
Stopping to validate MIR sounds like a really bad idea to me. MIR validation (in released compilers) has caught many critical issues already like #98608 (I found it while investigating a MIR validation failure that someone found in the wild because the mir typeck found something typeck let through) and the most recent let_chains problem which was also found because of a MIR validation ICE.
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-critical
- addedP-criticalCritical priorityCritical priorityand removedI-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}Issue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
on Aug 17, 2022 Reduced example:
pub trait Trait { type Associated; } impl<T> Trait for T { type Associated = T; } pub struct Struct<T>(<T as Trait>::Associated); pub fn foo<T>() -> Struct<T> where T: Trait, { bar() } #[inline] fn bar<T>() -> Struct<T> { Struct(baz()) } fn baz<T>() -> T { unimplemented!() }
Compiling playground v0.0.1 (/playground) error: internal compiler error: no errors encountered even though `delay_span_bug` issued error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:12 ~ playground[dc12]::foo), const_param_did: None }) (end of phase transition to Optimized) at bb1[1]: Field projection `_0.field[0]` specified type `T`, but actual type is <T as Trait>::Associated --> src/lib.rs:19:5 | 14 | bar() | ----- in this inlined function call ... 19 | Struct(baz()) | ^^^^^^^^^^^^^ | = note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:129:36 thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1426:13 stack backtrace: 0: std::panicking::begin_panic::<rustc_errors::ExplicitBug> 1: std::panic::panic_any::<rustc_errors::ExplicitBug> 2: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop 3: core::ptr::drop_in_place::<rustc_session::parse::ParseSess> 4: <alloc::rc::Rc<rustc_session::session::Session> as core::ops::drop::Drop>::drop 5: core::ptr::drop_in_place::<rustc_interface::interface::Compiler> 6: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_interface::interface::create_compiler_and_run<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#1}> 7: rustc_interface::interface::create_compiler_and_run::<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}> 8: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.64.0-beta.2 (fb2194acc 2022-08-14) running on x86_64-unknown-linux-gnu note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack error: could not compile `playground`@rustbot label S-bug-has-mcve
Reacted by Camille Gillot and Alexandre A. Bizri- addedS-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issueStatus: A Minimal Complete and Verifiable Example has been found for this issue
on Aug 19, 2022 Weird, this one crashes with
--crate-type lib -Copt-level=2but I couldn't get this to trigger with just mir-opt-levels 🤔- addedglacierICE tracked in rust-lang/glacier.ICE tracked in rust-lang/glacier.
on Aug 20, 2022
Code
ICE is triggered when building
nalgebra 0.25.4in filesrc\geometry\quaternion.rsin release mode. I'm not able to reproduce when building in debug mode. In my situation, thenalgebracrate is built as part of the dependency tree for a binary crate.Meta
rustc --version --verbose:Error output
Backtrace