[next-trait] semantic highlighting fails due to "db is expected to be attached"

[jhgg]

cc #20470

thread 'Worker6' panicked at crates/hir-ty/src/next_solver/interner.rs:292:10:
db is expected to be attached
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::option::expect_failed
   3: <hir_ty::next_solver::opaques::SolverDefIds as core::default::Default>::default
   4: hir_ty::traits::next_trait_solve
   5: hir_ty::traits::trait_solve_query
   6: hir_ty::method_resolution::iterate_trait_method_candidates
   7: hir_ty::method_resolution::iterate_method_candidates_dyn
   8: hir::attrs::resolve_doc_path_on_
   9: ide::doc_links::resolve_doc_path_for_def
  10: <alloc::vec::into_iter::IntoIter<T,A> as core::iter::traits::iterator::Iterator>::fold
  11: ide::syntax_highlighting::inject::doc_comment
  12: ide::syntax_highlighting::highlight
  13: salsa::cancelled::Cancelled::catch
  14: ide::Analysis::highlight_range
  15: rust_analyzer::handlers::request::handle_semantic_tokens_range
  16: core::ops::function::FnOnce::call_once{{vtable.shim}}
  17: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
additional context:
   0: 
version: 0.4.2586-standalone (a905e3b21b 2025-08-18)
request: textDocument/semanticTokens/range SemanticTokensRangeParams {
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
    text_document: TextDocumentIdentifier {
        uri: Url {
            scheme: "file",
            cannot_be_a_base: false,
            username: "",
            password: None,
            host: None,
            port: None,
            path: "/nix/store/9i76sv0p976dd756w8q82d1q60fjxfkb-rust-default-1.89.0-nightly-2025-06-02/lib/rustlib/src/rust/library/core/src/option.rs",
            query: None,
            fragment: None,
        },
    },
    range: Range {
        start: Position {
            line: 550,
            character: 0,
        },
        end: Position {
            line: 628,
            character: 0,
        },
    },
}

[ChayimFriedman2]

CC @Veykril, we are basically guaranteed to miss some cases to attach in highlighting. A lot of function calls can call hir-ty queries, so either we wrap every hir call in salsa::attach (horrible for readability plus we'll for sure forget some), or only the ones that need it (as the code currently tries to), which is even worse because there's no way we won't miss some over time plus this breaks the encapsulation.

I still think we should use our own reentrant thread local.

[Veykril]

I still don't see how that will help. The proper solution imo is still to expose a more ergonomic controllable API in salsa. We have to create that ourselves as well either way as we otherwise run risk of accidentally mixing DBs which is likely not fine?

[ChayimFriedman2]

The risk of mixing different DBs is pretty much next-to-not-existent. The risk however to forget some case is pretty much guaranteed. But sure, if Salsa can provide that API, so be it (although I still prefer our own API).