Is it expected that
cargo run -p rust-analyzer --release -- analysis-stats . --with-deps --parallel panics at https://github.com/rust-analyzer/rust-analyzer/blob/3191a93185b34c6deebca2aad0584d2840ad6d43/crates/hir_ty/src/traits/chalk/mapping.rs#L192 once whilst still pinnning the CPU?
It's not supposed to hit that panic
Ah. Well it apparently can :)
Looks like that code was recently added when adding
But yeah, Chalk sometimes returns lifetimes, and rust-analyzer should have some way to handle that instead of panicking
I think Jonas mentioned that already in another topic
@detrumi I am actually confused where Chalk would return a lifetime in a substitution without us telling it that it's expected
the mapping code will go away very soon anyway though
o_O it seems like we're actually requesting a goal with a lifetime variable... where does that come from
probably from another solution we got from Chalk...
oh yeah, probably autoderef
i was in a bisecting mood -- this panic seems to have been introduced in 590c41635952e19c3caae525a827499dbd360049 https://github.com/rust-analyzer/rust-analyzer/pull/8136
Interesting, I was assuming it started when the
unimplemented! line was added, but according to your bisect it was in before that?
That PR changed
Dyn types, so maybe that's the source of the lifetime?
are you sure that's not another crash? I think I fixed one introduced by that PR
I'm pretty sure I know what's going on with this one, but I think it will probably be fixed or need a different fix with the Chalk move, so I'm leaving it
yeah, it's 100% possible that my bisect found an unrelated crash
it crashes differently with the Chalk move now :grimacing:
progress, perhaps :)
rust-analyzer/rust-analyzer#8440 fixes it