Open mwcz opened 1 year ago
Looks like we're spinning in resolve_obligations_as_possible
. I didn't see it crash, though (I waited 10 minutes, with 10 000 lines, and it didn't finish).
That would have been my first guess from the description... The thing is, the obligations shouldn't be accumulating there. So the question is what the obligations are that can't get resolved immediately here.
Looks like we're spinning in
resolve_obligations_as_possible
. I didn't see it crash, though (I waited 10 minutes, with 10 000 lines, and it didn't finish).
For me, once it finishes, r-a works for a few seconds, and then crashes.
Wild guess: maybe it has to do with the integer type inference (and i32
fallback) for each Some(1)
? They will be slightly driven by PartialEq
as well.
Ah that's a good point, yeah, it's very likely related to that.
Something like Some(true)
or Some(())
would avoid type inference and PartialEq
, right? I gave that a try, and there's an improvement. r-a no longer crashes, but it does still take 2 minutes before becoming responsive.
I did some more evaluation and found a few interesting things.
The crash is due to a stack overflow.
$ time rust-analyzer diagnostics . 2>&1 | ts -s
00:00:02 processing crate: rust_analyzer_perf_fix, module: /home/users/projects/rust-analyzer-perf-fix/src/main.rs
00:04:23
00:04:23 thread 'main' has overflowed its stack
00:04:23 fatal runtime error: stack overflow
infer_expr_inner
jumps out in a flame graph. It's 94% of the total time, and appears to have been called about 300,000 times.
rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P)
r-a version reported by Mason:
installed version 2023-08-21
Version directly from r-a
rustc version: (eg. output of
rustc -V
)relevant settings: (eg. client settings, or environment variables like
CARGO
,RUSTC
,RUSTUP_HOME
orCARGO_HOME
)I'm using rust-analyzer in vim via Mason, and here's the settings dump shown by Mason:
rust-analyzer settings
I'm noticing some dramatic slowness, and crashing, in certain situations with a lot of assert macros.
Here's a minimal reproducer:
With that
assert_eq
duplicated, r-a runs on my machine for 6-7 minutes, seems to finish processing the crate and works for a few seconds (showing hover info, etc), and then crashes (code 0, signal 6). While running, it pegs two cores at 100%, and memory usage hovers around 640MB.Having so many asserts seems excessive, but I have a real-wold case where having the asserts is helpful. I can find a workaround, but there seems to be something worth looking at here since other variations of "many asserts" work without a hitch.
As a couterexample, r-a has no trouble at all with this example: