~30s hangs in diagnostic updates

[andreaskrath]

I am experiencing upwards of 30 seconds hangs after a write a file, until all diagnostics have correctly applied and rust-analyzer stops working and analyzing my submitted code.

I have tested different configurations for rust-analyzer (my normal config, and full default config), and different editors (Neovim, Helix, and VSCode) and they all have the same issue.

Below I have attached some Neovim LSP logs that showcases a delay of about 30 seconds before the communication fully finishes - granted I do not fully understand what these messages are about, I can just observe than when the last messages are received, is when rust-analyzer stops working, and the diagnostics are correctly applied.

Neovim LSP logs

[DEBUG][2025-08-30 01:01:10] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ jsonrpc = "2.0", method = "textDocument/publishDiagnostics", params = { diagnostics = { { code = "unused_variables", data = { rendered = "warning: unused variable: `err`\n --> api/src/spell/handler.rs:9:16\n  |\n9 |     if let Err(err) = spell_repo.create(spell).await {\n  |                ^^^ help: if this is intentional, prefix it with an underscore: `_err`\n\n" }, message = "unused variable: `err`", range = { ["end"] = { character = 18, line = 8 }, start = { character = 15, line = 8 } }, relatedInformation = { { location = { range = { ["end"] = { character = 18, line = 8 }, start = { character = 15, line = 8 } }, uri = "file:///home/krath/Documents/combat-tracker/api/src/spell/handler.rs" }, message = "if this is intentional, prefix it with an underscore: `_err`" } }, severity = 2, source = "rustc", tags = { 1 } }, { code = "unused_variables", message = "if this is intentional, prefix it with an underscore: `_err`", range = { ["end"] = { character = 18, line = 8 }, start = { character = 15, line = 8 } }, relatedInformation = { { location = { range = { ["end"] = { character = 18, line = 8 }, start = { character = 15, line = 8 } }, uri = "file:///home/krath/Documents/combat-tracker/api/src/spell/handler.rs" }, message = "original diagnostic" } }, severity = 4, source = "rustc" }, { code = "unused_variables", data = { rendered = "warning: unused variable: `err`\n  --> api/src/spell/handler.rs:19:13\n   |\n19 |         Err(err) => StatusCode::INTERNAL_SERVER_ERROR.into_response(),\n   |             ^^^ help: if this is intentional, prefix it with an underscore: `_err`\n\n" }, message = "unused variable: `err`", range = { ["end"] = { character = 15, line = 18 }, start = { character = 12, line = 18 } }, relatedInformation = { { location = { range = { ["end"] = { character = 15, line = 18 }, start = { character = 12, line = 18 } }, uri = "file:///home/krath/Documents/combat-tracker/api/src/spell/handler.rs" }, message = "if this is intentional, prefix it with an underscore: `_err`" } }, severity = 2, source = "rustc", tags = { 1 } }, { code = "unused_variables", message = "if this is intentional, prefix it with an underscore: `_err`", range = { ["end"] = { character = 15, line = 18 }, start = { character = 12, line = 18 } }, relatedInformation = { { location = { range = { ["end"] = { character = 15, line = 18 }, start = { character = 12, line = 18 } }, uri = "file:///home/krath/Documents/combat-tracker/api/src/spell/handler.rs" }, message = "original diagnostic" } }, severity = 4, source = "rustc" } }, uri = "file:///home/krath/Documents/combat-tracker/api/src/spell/handler.rs" } }
[DEBUG][2025-08-30 01:01:10] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ jsonrpc = "2.0", method = "$/progress", params = { token = "rust-analyzer/flycheck/0", value = { cancellable = true, kind = "report", message = "combat_tracker" } } }
[DEBUG][2025-08-30 01:01:10] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ jsonrpc = "2.0", method = "$/progress", params = { token = "rust-analyzer/flycheck/0", value = { cancellable = true, kind = "report", message = "combat_tracker" } } }
[DEBUG][2025-08-30 01:01:10] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ jsonrpc = "2.0", method = "$/progress", params = { token = "rust-analyzer/flycheck/0", value = { cancellable = true, kind = "report", message = "combat-tracker" } } }
[DEBUG][2025-08-30 01:01:10] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ jsonrpc = "2.0", method = "$/progress", params = { token = "rust-analyzer/flycheck/0", value = { cancellable = true, kind = "report", message = "combat-tracker" } } }
[DEBUG][2025-08-30 01:01:10] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ jsonrpc = "2.0", method = "$/progress", params = { token = "rust-analyzer/flycheck/0", value = { kind = "end" } } }
[DEBUG][2025-08-30 01:01:40] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ id = 18, jsonrpc = "2.0", result = { items = {}, kind = "full", resultId = "rust-analyzer" } }
[DEBUG][2025-08-30 01:01:40] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ id = 19, jsonrpc = "2.0", result = { items = {}, kind = "full", resultId = "rust-analyzer" } }
[DEBUG][2025-08-30 01:01:40] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ id = 17, jsonrpc = "2.0", result = { items = {}, kind = "full", resultId = "rust-analyzer" } }
[DEBUG][2025-08-30 01:01:40] .../vim/lsp/rpc.lua:391	"rpc.receive"	{ id = 16, jsonrpc = "2.0", result = { items = {}, kind = "full", resultId = "rust-analyzer" } }

I work with quite a few macros in my code, mostly sqlx and serde derives, and from my primitive testing this issue of hanging is essentially resolved if I remove these macros (although due to functionality this is not really reasonable to do).

When I check rust-analyzer logs, I see a bunch of logs related to shim which I do not know what is, but some examples are:

• attrs_shim
• impl_items_with_diagnostics_shim
• generic_predicates_shim
• impl_datum_shim
• struct_signature_with_source_map_shim

And many many more, there are also a few without the shim suffix, though not a lot.

Looking at the rust-analyzer logs for this (I may have missed something here as the log file for this very small check and example is over 600k lines), there seems to be a couple of seconds of indexing when I open the editor (~10 seconds), which is very reasonable.

When I write my file, and a new request begins I see the following:

• 01:43:11.139988574 new request starts (at least I think so, there is a major time-gap before the previous log to this log), this is at around line 187k in the log file
• 01:43:52.20375824 the request is done processing, this is at around line 614k in the log file
• The log progresses quite steadily with a small delay between each log for the essentially the entire line span above, and around line 614k trait solving begins, which really slows down a ton
• From line 614109 to line 614830 around 25-30 seconds is spent only on trait solving essentially, at least the only log message I see for this section is trait_solve_shim(<id>): executing query

I know that these time stamps do not match the Neovim LSP timestamps, as I recorded these at different times - but I am testing the same file change in both scenarios, and the "feel" is exactly the same in both scenarios.

Sorry for the "rant", but I want to provide as much information as possible. My question really is quite simple, I am wondering if this is the expected behaviour. I know that trait solving is very complex, but outside of my code using the sqlx and serde derive macros, it is a relatively lean project I would say, at least in comparison to a lot of other projects I have seen.

I am wondering if there is anything I could do to improve this on my end, because it kills a lot of my workflow that I have to wait around 30 seconds on each file save to get diagnostics for my changes. It also somewhat confuses me why indexing can somehow be relatively fast, although I assume some things are cached here, when the trait solving afterwards is to incredibly slow.

I am not using the new trait solver.

Thanks in advance for anyone who takes the time to read this, and provides any feedback or help. It is greatly appreciated!

[ChayimFriedman2]

Do you have debug logging enabled? That can slow down r-a quite significantly.

[andreaskrath]

Even without debug logging or without any logging whatsoever, I still encounter around the same delay. I have only ever enabled logging to inspect what was going on with the delay.

[ChayimFriedman2]

Can you set the environment variable RA_PROFILE='*>100' and post the logs?

[andreaskrath]

2025-08-31T00:03:48.828281975+02:00 ERROR overly long loop turn took 497.080026ms (event handling took 497.065107ms): PrimeCaches(Report(ParallelPrimeCachesProgress { crates_currently_indexing: [], crates_total: 12, crates_done: 12, work_type: "Populating symbols" }))

This is the only logged line for the scenario. I also get this as an LSP error around the time when indexing completes - but I can still see that rust-analyzer is working for around 30 seconds after that, but not logs for any of it.

[ChayimFriedman2]

Can you leave it for some long time with this environment variable and see if it writes something?

Also, is your code public?

[andreaskrath]

This is the specific file I encounter the issue in. Again, I know there is quite heavy macro use, but I still personally feel like 30 seconds or more to resolve everything seems excessive.

[ChayimFriedman2]

This file contains a giant struct with a heavy macro on top.

Now, of course 30s is a lot, and we don't want rust-analyzer to take that long, but given that we should expect r-a to be slow with large structs with large macros (and traits probably as well), this probably means your complaint translates to "r-a is slow", to which the answer is: we know, we're always working on it, there is no magic bullet.

If this would be a regression, for example, we would have a reason to believe it's not normal and something fishy is going on. But this is not.

Perhaps I'll be able to take a deeper look at the file somewhen later, but my hunch is that there is nothing exceptional here. And if I'm correct, that basically means we have no way to help (and also, that opening another issue didn't help, although of course you couldn't know). If native diagnostics are slow for you, you can disable them.