Request textDocument/completion failed: can't resolve SyntaxNodePtr { kind: FN, range: 0..1441 } with MACRO_ITEMS@0..1047

[wgreenberg]

rust-analyzer version: 0.3.1807-standalone

rustc version: rustc 1.75.0 (82e1608df 2023-12-21)

relevant settings: None that I can tell

While working on this branch of noclip.website in VSCode, I get consistent textDocument/completion failures after a few minutes of rust code editing. Things will work for a few minutes, and then every file save will trigger the following failure:

version: 0.3.1807-standalone
request: textDocument/completion CompletionParams {
    text_document_position: TextDocumentPositionParams {
        text_document: TextDocumentIdentifier {
            uri: Url {
                scheme: "file",
                cannot_be_a_base: false,
                username: "",
                password: None,
                host: None,
                port: None,
                path: "/home/willg/dev/etc/noclip.website/rust/src/wow/wmo.rs",
                query: None,
                fragment: None,
            },
        },
        position: Position {
            line: 77,
            character: 41,
        },
    },
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
    context: Some(
        CompletionContext {
            trigger_kind: Invoked,
            trigger_character: None,
        },
    ),
}

thread 'Worker' panicked at /github/home/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rowan-0.15.15/src/ast.rs:73:50:
can't resolve SyntaxNodePtr { kind: FN, range: 0..1441 } with MACRO_ITEMS@0..1047
stack backtrace:
   0: rust_begin_unwind
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
   2: rowan::ast::SyntaxNodePtr<L>::to_node
   3: syntax::ptr::AstPtr<N>::to_node
   4: <hir_def::AssocItemLoc<N> as hir_def::src::HasSource>::source
   5: hir::symbols::SymbolCollector::push_decl
   6: hir::symbols::SymbolCollector::collect_from_module
   7: hir::symbols::SymbolCollector::collect
   8: hir::symbols::SymbolCollector::collect_module
   9: <ide_db::symbol_index::ModuleSymbolsQuery as salsa::plumbing::QueryFunction>::execute
  10: salsa::Cycle::catch
  11: salsa::derived::slot::Slot<Q,MP>::execute
  12: salsa::derived::slot::Slot<Q,MP>::read
  13: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::fetch
  14: alloc::vec::in_place_collect::<impl alloc::vec::spec_from_iter::SpecFromIter<T,I> for alloc::vec::Vec<T>>::from_iter
  15: <alloc::boxed::Box<[I]> as core::iter::traits::collect::FromIterator<I>>::from_iter
  16: ide_db::symbol_index::crate_symbols
  17: ide_db::items_locator::items_with_name
  18: ide_db::imports::import_assets::ImportAssets::search_for
  19: ide_db::imports::import_assets::ImportAssets::search_for_imports
  20: ide_completion::completions::complete_name_ref
  21: ide_completion::completions
  22: ide::Analysis::completions
  23: rust_analyzer::handlers::request::handle_completion
  24: std::panicking::try
  25: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[Error - 2:40:37 PM] Request textDocument/completion failed.
  Message: request handler panicked: can't resolve SyntaxNodePtr { kind: FN, range: 0..1441 } with MACRO_ITEMS@0..1047
  Code: -32603 

Note that this happens on both Windows and Linux. Happy to provide more info if needed, thanks!

[bewee-i]

I'm facing the very same issue on 1.77.1 (7cf61eb 2024-03-27)

[Veykril]

Panicking location is

rust-analyzer/crates/hir/src/symbols.rs

Line 284 in 9cced6d

let source = loc.source(self.db.upcast());

Which seems bad, that means we create an invalid interned location? Presuambly in the code is a macro call or attribute on an associated item somewhere given the backtrace, so we handle something wrongly for that

[Veykril]

Do you have a repro with specific steps? I can't reproduce this by just querying for completions with the given repository

[rix0rrr]

Seeing the same issue on version: 0.4.1954-standalone (5bf2f85c8 2024-05-09) and version: 0.4.1957-standalone (5bf2f85c8 2024-05-09).

Unfortunately not in a repository that I can share :(

[rix0rrr]

The problem doesn't occur deterministically. It seems to crop up after a while, and then requires restarting the analyzer. This seems to be consistent with your thoughts that it might be some kind of cache poisoning.