You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm getting broken MIR errors in about each 10th of my let-else usages. I think it's related to incremental compilation since if never happens on a fresh first-time Clippy run.
Unfortunately, I'm unable to reproduce it in an isolated project, but the code is OSS - here are a few snippets:
warning: Error finalizing incremental compilation session directory `/Users/eugene/Work/warpgate/target/debug/incremental/warpgate_protocol_mysql-2e3tgexhc7x8e/s-gf31whx4hw-1ja190i-working`: No such file or directory (os error 2)
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:68 ~ warpgate_protocol_mysql[9d48]::client::{impl#1}::connect::{closure#0}), const_param_did: None }) (after pass PhaseChange-Runtime(Optimized)) at bb1145[0]:
use of local _1023, which has no storage here
--> warpgate-protocol-mysql/src/client.rs:151:10
|
151 | };
| ^
|
= note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36
error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:263 ~ warpgate_protocol_mysql[9d48]::session::{impl#0}::passthrough_until_result::{closure#0}), const_param_did: None }) (after pass PhaseChange-Runtime(Optimized)) at bb257[0]:
use of local _11, which has no storage here
--> warpgate-protocol-mysql/src/session.rs:420:14
|
420 | };
| ^
|
= note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36
thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1530: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-clippy/issues/new
note: Clippy version: clippy 0.1.65 (8ce3204a 2022-09-30)
query stack during panic:
end of query stack
The text was updated successfully, but these errors were encountered:
@Eugeny can you still reproduce it with latest master?
Your bug looks a lot like rust-lang/rust#102317 which was fixed Oct 6 in rustc master, and in the rustup after that in clippy. Your toolchain is from end of September so doesn't have the fix yet.
I'm getting
broken MIR
errors in about each 10th of my let-else usages. I think it's related to incremental compilation since if never happens on a fresh first-time Clippy run.Unfortunately, I'm unable to reproduce it in an isolated project, but the code is OSS - here are a few snippets:
Code: https://github.com/warp-tech/warpgate/blob/main/warpgate-protocol-mysql/src/client.rs#L149-L151
Code: https://github.com/warp-tech/warpgate/blob/main/warpgate-protocol-mysql/src/session.rs#L418-L420
The text was updated successfully, but these errors were encountered: