`completion.termSearch` textDocument/completion LSP request handler panic

[VivIsBee]

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

rustc version: rustc 1.95.0-nightly (f889772d6 2026-02-05)

editor or extension: VSCode 0.3.2777

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME)

  // ...
  "rust-analyzer.completion.termSearch.enable": true,
  // ...

repository link (if public, optional):

code snippet to reproduce:

I have this problem where, sometimes, it will show a notification that "Request textDocument/completion failed." and it, of course, won't show completion suggestions when I begin typing in anything. Unfortunately, I'm not 100% sure how to reproduce it. However, it seems to crop up randomly inside any amount of nesting within a function call's arguments. I think it might happen within the main function exclusively? I don't have time to isolate too much right now (sorry! I'll try more when I have the time). I have isolated it specifically to rust-analyzer.completion.termSearch.enable, as disabling it completely fixes the issue. The full error from the logs:

thread 'Worker3' (354303) panicked at /github/home/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ra-ap-rustc_type_ir-0.143.0/src/binder.rs:784:9:
type parameter `#1` (#1/1) out of range when instantiating, args=[#1]
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: ra_ap_rustc_type_ir::binder::ArgFolder<I>::type_param_out_of_range
   3: <ra_ap_rustc_type_ir::binder::ArgFolder<I> as ra_ap_rustc_type_ir::fold::TypeFolder<I>>::fold_ty
   4: <hir_ty::next_solver::generic_arg::GenericArgs as ra_ap_rustc_type_ir::fold::TypeFoldable<hir_ty::next_solver::interner::DbInterner>>::fold_with
   5: ra_ap_rustc_type_ir::predicate_kind::_::<impl ra_ap_rustc_type_ir::fold::TypeFoldable<I> for ra_ap_rustc_type_ir::predicate_kind::ClauseKind<I>>::fold_with
   6: <hir_ty::next_solver::predicate::Clause as ra_ap_rustc_type_ir::inherent::Clause<hir_ty::next_solver::interner::DbInterner>>::instantiate_supertrait
   7: <ra_ap_rustc_type_ir::elaborate::Elaborator<I,O> as core::iter::traits::iterator::Iterator>::next
   8: <T as ra_ap_rustc_type_ir::interner::CollectAndApply<T,R>>::collect_and_apply
   9: hir_ty::builtin_derive::param_env
  10: hir::Function::fn_ptr_type
  11: hir::Function::fn_sig
  12: hir::Function::ret_type
  13: hir::Function::ret_type_with_args
  14: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
  15: <alloc::vec::into_iter::IntoIter<T,A> as core::iter::traits::iterator::Iterator>::try_fold
  16: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
  17: <alloc::vec::into_iter::IntoIter<T,A> as core::iter::traits::iterator::Iterator>::try_fold
  18: <alloc::vec::into_iter::IntoIter<T,A> as core::iter::traits::iterator::Iterator>::try_fold
  19: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
  20: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
  21: hir::term_search::term_search
  22: ide_completion::completions::expr::complete_expr
  23: ide_completion::completions::complete_name_ref
  24: ide_completion::completions
  25: salsa::cancelled::Cancelled::catch
  26: std::thread::local::LocalKey<T>::with
  27: ide::Analysis::completions
  28: rust_analyzer::handlers::request::handle_completion
  29: core::ops::function::FnOnce::call_once{{vtable.shim}}
  30: <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.3.2777-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: "[path to the crate]/src/main.rs",
                query: None,
                fragment: None,
            },
        },
        position: Position {
            line: 10,
            character: 80,
        },
    },
    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,
        },
    ),
}

[Error - 7:57:17 PM] Request textDocument/completion failed.
  Message: request handler panicked: type parameter `#1` (#1/1) out of range when instantiating, args=[#1]
  Code: -32603

[Dzuchun]

I appear to have encountered a similar panictrace. reproduced on 02-02, 09-02 and 16-02 versions.

I am using a nvim-lsp setup.

Setting completion.termSearch.enable to false resolves this issue for me.

However, before finding this thread, I've managed to isolate a minimal example:

fn f(_: i32) {}

fn main() {
    let _a = Ok::<(), ()>(());
    f(); // <-- ask for completions in the parentheses here
}

attempt to see completions for f's arguments causes the panic for me

notes:

• completions in any other context work fine, only function arguments appear to be a problem
• removing the definition of _a removes the problem
• renaming _a to _ removes the problem
• replacing with let _a = Result::<(), ()>::Ok(()) does not remove the panic
• using alias R<A, B> = Result<A, B> removes that problem (yeah, I double-checked that)
• using a self-defined two-argument type like struct S<A, B>(::core::marker::PhantomData<(A, B)>); instead of Result removed the problem

Unfortunately, I wasn't able to reproduce this panic via manual json rpc requests. So simple initialize-initialized-textDocument/didConfigChange(with my config)-textDocument/didOpen-textDocument/completion was not enough to reproduce the panic.