Rust-analyze practically unusable when working on rustc, many Can't find FN@482..771 in AstIdMap: ICEs

[compiler-errors]

rust-analyzer version: rust-analyzer version: 0.4.2156-standalone [/home/mgx/.vscode-server/extensions/rust-lang.rust-analyzer-0.4.2156-linux-x64/server/rust-analyzer]

rustc version: bootstrap rustc, so it should be beta 1.83.0-beta.2

editor or extension: vscode

relevant settings: I'm building in rustc, so the default .vscode/settings.json that it ships on ./x.py setup.

repository link (if public, optional): rustc

repro: I have none, since it happens when editing code in the codebase.

---

Every 5 minutes or so, rust-analyzer catastrophically begins failing with:

thread 'Worker' panicked at crates/span/src/ast_id.rs:226:21:
Can't find FN@482..771 in AstIdMap:
[SyntaxNodePtr { kind: MACRO_ITEMS, range: 0..770 }, SyntaxNodePtr { kind: CONST, range: 0..482 }, SyntaxNodePtr { kind: FN, range: 482..770 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 10..481 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 538..770 }, SyntaxNodePtr { kind: IMPL, range: 11..480 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 632..769 }, SyntaxNodePtr { kind: FN, range: 115..479 }, SyntaxNodePtr { kind: MACRO_CALL, range: 633..767 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 245..479 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 311..477 }, SyntaxNodePtr { kind: MACRO_CALL, range: 416..435 }]
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: span::ast_id::AstIdMap::erased_ast_id
   3: hir_def::item_tree::lower::Ctx::lower_function
   4: hir_def::item_tree::lower::Ctx::lower_mod_item
   5: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
   6: hir_def::item_tree::lower::Ctx::lower_module_items
   7: hir_def::item_tree::ItemTree::file_item_tree_query
   8: ra_salsa::Cycle::catch
   9: ra_salsa::derived::slot::Slot<Q>::execute
  10: ra_salsa::derived::slot::Slot<Q>::read
  11: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
  12: <DB as hir_def::db::DefDatabase>::file_item_tree
  13: hir_def::nameres::collector::DefCollector::collect_macro_expansion
  14: hir_def::nameres::collector::collect_defs
  15: hir_def::nameres::DefMap::crate_def_map_query
  16: ra_salsa::Cycle::catch
  17: ra_salsa::derived::slot::Slot<Q>::execute
  18: ra_salsa::derived::slot::Slot<Q>::read
  19: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
  20: <DB as hir_def::db::DefDatabase>::crate_def_map
  21: hir_def::nameres::path_resolution::<impl hir_def::nameres::DefMap>::resolve_path_fp_with_macro_single
  22: hir_def::nameres::path_resolution::<impl hir_def::nameres::DefMap>::resolve_path_fp_with_macro
  23: hir_def::nameres::collector::DefCollector::resolve_import
  24: <alloc::vec::into_iter::IntoIter<T,A> as core::iter::traits::iterator::Iterator>::try_fold
  25: hir_def::nameres::collector::collect_defs
  26: hir_def::nameres::DefMap::crate_def_map_query
  27: ra_salsa::Cycle::catch
  28: ra_salsa::derived::slot::Slot<Q>::execute
  29: ra_salsa::derived::slot::Slot<Q>::read
  30: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
  31: <DB as hir_def::db::DefDatabase>::crate_def_map
  32: hir::semantics::source_to_def::SourceToDefCtx::file_to_def
  33: hir::semantics::SemanticsImpl::file_to_module_defs
  34: hir::semantics::SemanticsImpl::attach_first_edition
  35: ide::syntax_highlighting::highlight
  36: ra_salsa::Cancelled::catch
  37: rust_analyzer::handlers::request::handle_semantic_tokens_full
  38: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[Error - 4:55:12 PM] Request textDocument/semanticTokens/full failed.
  Message: request handler panicked: Can't find FN@482..771 in AstIdMap:
[SyntaxNodePtr { kind: MACRO_ITEMS, range: 0..770 }, SyntaxNodePtr { kind: CONST, range: 0..482 }, SyntaxNodePtr { kind: FN, range: 482..770 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 10..481 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 538..770 }, SyntaxNodePtr { kind: IMPL, range: 11..480 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 632..769 }, SyntaxNodePtr { kind: FN, range: 115..479 }, SyntaxNodePtr { kind: MACRO_CALL, range: 633..767 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 245..479 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 311..477 }, SyntaxNodePtr { kind: MACRO_CALL, range: 416..435 }]
  Code: -32603 

---

Interestingly:

Can't find FN@482..771 in AstIdMap:

Given:

[SyntaxNodePtr { kind: MACRO_ITEMS, range: 0..770 }, SyntaxNodePtr { kind: CONST, range: 0..482 }, SyntaxNodePtr { kind: FN, range: 482..770 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 10..481 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 538..770 }, SyntaxNodePtr { kind: IMPL, range: 11..480 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 632..769 }, SyntaxNodePtr { kind: FN, range: 115..479 }, SyntaxNodePtr { kind: MACRO_CALL, range: 633..767 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 245..479 }, SyntaxNodePtr { kind: BLOCK_EXPR, range: 311..477 }, SyntaxNodePtr { kind: MACRO_CALL, range: 416..435 }]

Notice that SyntaxNodePtr { kind: FN, range: 482..770 } exists in that list 🤔 Is this an off-by-one bug somewhere in syntax expansion or something in r-a? Is there some way that r-a can actually share what these syntax nodes are called or render their spans more gracefully so I could debug what their origin is?

---

Also, specifically, is there any way for me to get rust-analyzer to just gracefully restart itself when it gets stuck in this situation? I don't want to flat-out, but basically rust-analyzer is getting itself stuck due to some new regression that has happened in the last few weeks or so, and I have basically no idea what to do at this point.

I am basically being barraged with toaster popups from vscode when I do anything (move my cursor, type a character, look at vscode wrong) until I restart rust-analyzer. I've had to CTRL + SHIFT + P > restart rust analyzer basically every 5 minutes (like, literally hundreds of times) for weeks now.

[compiler-errors]

Duplicated #18228, #17575. Funny enough that Alexendoo's report was also reported from working on rustc.

[compiler-errors]

Also I will note that I'm happy to help out with live-debugging this, if anyone needs help reproducing it. This happens almost constantly IME, so it shouldn't be too hard to repro on my side.

[davidbarsky]

Also, specifically, is there any way for me to get rust-analyzer to just gracefully restart itself when it gets stuck in this situation? I don't want to flat-out, but basically rust-analyzer is getting itself stuck due to some new regression that has happened in the last few weeks or so, and I have basically no idea what to do at this point.

It should be gracefully restarting, but if it's fully crashing... well, we're talking on this issue. For debugging, it might be useful to run the command (accessible through the VS Code Command Palette; Command + Shift + P) rust-analyzer (debug command): Show Syntax Tree and pasting the resulting output in a gist. This might be useful if the crash is in the file you're editing, but it's in a dependency... I'm less confident about that.

@compiler-errors I got some time to go on a video call in the next couple hours?

[Veykril]

Its not crashing, its getting into an inconsistent state wrt to the database causing everything to just panic. If it was crashing/panicking outside the catchers vscode would restart it properly.

[Veykril]

I assume you have a ton of ram to spare right? :) Can you set "rust-analyzer.lru.capacity" to something very high? Like 10000 (default is 128). That affects the LRU cache size for our parse queries (quadrupled for the macro ones iirc), curious to see if that reduces the frequency of this. (might need to restart when changing that I don't remember)