thread '<unnamed>' panicked at 'not implemented', /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\macros.rs:13:23

[Geobert]

Yesterday, using VSCode, I don't know why, but RA suddenly stopped working at all. No navigation, no semantic highlighting with this error:

thread '<unnamed>' panicked at 'not implemented', /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\macros.rs:13:23
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: <unknown>
  29: <unknown>
  30: <unknown>
  31: <unknown>
  32: <unknown>
  33: <unknown>
  34: <unknown>
  35: <unknown>
  36: <unknown>
  37: <unknown>
  38: <unknown>
  39: <unknown>
  40: <unknown>
  41: <unknown>
  42: <unknown>
  43: <unknown>
  44: <unknown>
  45: <unknown>
  46: <unknown>
  47: <unknown>
  48: <unknown>
  49: <unknown>
  50: <unknown>
  51: <unknown>
  52: <unknown>
  53: <unknown>
  54: BaseThreadInitThunk
  55: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Panic context:
> request: textDocument/definition GotoDefinitionParams {
    text_document_position_params: TextDocumentPositionParams {
        text_document: TextDocumentIdentifier {
            uri: "file:///c%3A/Users/geobe/work/my_project/src/server.rs",
        },
        position: Position {
            line: 44,
            character: 65,
        },
    },
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
}

and in extension host logs, this message multiple times:

[2020-10-01 11:20:32.716] [exthost] [error] [matklad.rust-analyzer] provider FAILED
[2020-10-01 11:20:32.717] [exthost] [error] Canceled: Canceled
	at LanguageClient.makeCancelError (c:\Users\geobe\.vscode\extensions\matklad.rust-analyzer-0.3.331-nightly\out\src\main.js:11804:24)
	at LanguageClient.handleFailedRequest (c:\Users\geobe\.vscode\extensions\matklad.rust-analyzer-0.3.331-nightly\out\src\main.js:11794:28)
	at c:\Users\geobe\.vscode\extensions\matklad.rust-analyzer-0.3.331-nightly\out\src\main.js:14748:28

Then I rollback to stable and is was still broken, but after deleting target/rls it started to work again 😕

As it was working again after deleting the target/rls, I switched to nightly again, and it was working… The "provider FAILED" logs in the extension host logs was still present though.

Today, I updated the nightly like everyday, and it was broken again :-/ same errors in boths logs.

Reverted to stable, and it works even if I get the extensions host log:

[2020-10-02 09:30:16.942] [exthost] [error] [matklad.rust-analyzer] provider FAILED
[2020-10-02 09:30:16.943] [exthost] [error] Canceled: Canceled
	at LanguageClient.makeCancelError (c:\Users\geobe\.vscode\extensions\matklad.rust-analyzer-0.2.328\out\src\main.js:11804:24)
	at LanguageClient.handleFailedRequest (c:\Users\geobe\.vscode\extensions\matklad.rust-analyzer-0.2.328\out\src\main.js:11794:28)
	at c:\Users\geobe\.vscode\extensions\matklad.rust-analyzer-0.2.328\out\src\main.js:14742:28

PS: was posted here as well: https://users.rust-lang.org/t/ra-totally-broken-since-1st-oct-version/49529/7

[Veetaha]

Same for me here, started seeing this on today's new nightly version:

rust-analyzer version: nightly (505ff40)

cc #5651

[kjeremy]

Are you sue you don't have the rls extension enabled? It's suspicious that deleting the target/rls directory fixed it. Also are you on the latest stable vscode? You may want to compile the extension yourself and enable debug info for a good stack trace.

[Geobert]

I'm pretty sure, I don't know how this target/rls appeared as I stopped using RLS for over a year and I don't recall installing it on my work laptop (new job started in January).

I might be wrong and maybe I've done some test (installing RLS to see something and immediatly uninstall it?) that I don't remember. But it seems very unlikely to me, but plausible

[lnicola]

@Geobert did you enable the proc macro support? If so, can you try with #5651?

[Geobert]

@lnicola I don't think so as I didn't know there was such support ^^'

"rust-analyzer.inlayHints.parameterHints": false,
    "rust-analyzer.inlayHints.typeHints": false,
    "rust-analyzer.inlayHints.chainingHints": true,
    "rust-analyzer.updates.askBeforeDownload": false,
    "rust-analyzer.lens.enable": false,
    "rust-analyzer.updates.channel": "stable",

[lnicola]

I guess you could try to switch to the nightly channel, so you might get better a better backtrace.

[Geobert]

It was on nightly when I got the issues, I switched back to stable in order to have something that works :)

Switched back to nightly to test:

Panic context:
> request: textDocument/codeAction CodeActionParams {
    text_document: TextDocumentIdentifier {
        uri: "file:///c%3A/Users/geobe/work/my_project/src/server.rs",
    },
    range: Range {
        start: Position {
            line: 190,
            character: 12,
        },
        end: Position {
            line: 191,
            character: 62,
        },
    },
    context: CodeActionContext {
        diagnostics: [],
        only: None,
    },
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
}

thread '<unnamed>' panicked at 'not implemented', /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\macros.rs:13:23
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: <unknown>
  29: <unknown>
  30: <unknown>
  31: <unknown>
  32: <unknown>
  33: <unknown>
  34: <unknown>
  35: <unknown>
  36: <unknown>
  37: <unknown>
  38: <unknown>
  39: <unknown>
  40: <unknown>
  41: <unknown>
  42: <unknown>
  43: <unknown>
  44: <unknown>
  45: <unknown>
  46: <unknown>
  47: <unknown>
  48: <unknown>
  49: <unknown>
  50: <unknown>
  51: BaseThreadInitThunk
  52: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[lnicola]

I meant the nightly rust-analyzer version, rust-analyzer.updates.channel.

[Geobert]

Yes, that's what I did :)

[Veetaha]

I am afraid this bug has made it to the new stable release.
Here is my stack trace (I have removed particular crate names and paths in the output, because the project is private):

The server logs

[ERROR project_model] cyclic dependency [[REDACTED]]
[ERROR project_model] cyclic dependency [[REDACTED]]
[ERROR project_model] cyclic dependency [[REDACTED]]
[ERROR project_model] cyclic dependency [[REDACTED]]
Panic context:
> request: textDocument/semanticTokens/full SemanticTokensParams {
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
    text_document: TextDocumentIdentifier {
        uri: "file:///home/veetaha/[[REDACTED]]",
    },
}

thread '<unnamed>' panicked at 'not implemented', /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/macros.rs:13:23
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: std::thread::local::LocalKey<T>::with
  11: stdx::panic_context::PanicContext::init::{{closure}}
  12: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:530
  13: std::panicking::begin_panic
  14: chalk_solve::clauses::push_auto_trait_impls
  15: chalk_solve::clauses::builder::ClauseBuilder<I>::push_binders
  16: chalk_solve::clauses::program_clauses_that_could_match
  17: chalk_solve::clauses::program_clauses_for_goal
  18: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  19: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::prove
  20: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::solve
  21: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  22: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::prove
  23: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::solve
  24: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  25: <chalk_recursive::recursive::RecursiveSolver<I> as chalk_solve::solve::Solver<I>>::solve_limited
  26: hir_ty::traits::trait_solve_query
  27: salsa::runtime::Runtime::execute_query_implementation
  28: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  29: salsa::derived::slot::Slot<Q,MP>::read
  30: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  31: salsa::QueryTable<Q>::get
  32: <DB as hir_ty::db::HirDatabase>::trait_solve::__shim
  33: <DB as hir_ty::db::HirDatabase>::trait_solve
  34: hir_ty::infer::InferenceContext::resolve_ty_as_possible
  35: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  36: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::check_call_arguments
  37: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_method_call
  38: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  39: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr
  40: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_method_call
  41: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  42: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr
  43: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_method_call
  44: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  45: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr
  46: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_method_call
  47: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  48: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr
  49: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_method_call
  50: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  51: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  52: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  53: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  54: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  55: hir_ty::infer::infer_query
  56: salsa::runtime::Runtime::execute_query_implementation
  57: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  58: salsa::derived::slot::Slot<Q,MP>::read
  59: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  60: <DB as hir_ty::db::HirDatabase>::infer_query::__shim
  61: hir_ty::db::infer_wait
  62: hir::source_analyzer::SourceAnalyzer::new_for_body
  63: hir::semantics::SemanticsImpl::analyze2
  64: hir::semantics::SemanticsImpl::resolve_bind_pat_to_const
  65: ide_db::defs::classify_name
  66: ide::syntax_highlighting::highlight_element
  67: ide::syntax_highlighting::highlight
  68: ide::Analysis::highlight
  69: rust_analyzer::handlers::handle_semantic_tokens_full
  70: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Geobert]

@Veetaha how did you get this stack trace? Mine is full of <unknown> :-/

[Geobert]

rust-lang/chalk#621

[Veetaha]

I don't know, I used the stable build. IIRC only nightlies capture the debug symbols info for better stack traces, but this may have changed

[lnicola]

It might be platform-specific. Veetaha is using Linux IIRC, while you're on Windows. MSVC debug symbols are usually in a different file (.pdb), but I don't know what we use to build Windows binaries.