thread 'Worker' panicked at 'called Option::unwrap() on a None value', /github/home/.cargo/registry/src/github.com-1ecc6299db9ec823/chalk-solve-0.86.0/src/clauses/builtin_traits/fn_family.rs:90:55

[bjorn3]

While working on cg_clif:

thread 'Worker' panicked at 'called `Option::unwrap()` on a `None` value', /github/home/.cargo/registry/src/github.com-1ecc6299db9ec823/chalk-solve-0.86.0/src/clauses/builtin_traits/fn_family.rs:90:55
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
   3: chalk_solve::clauses::builtin_traits::fn_family::add_fn_trait_program_clauses
   4: chalk_solve::clauses::builder::ClauseBuilder<I>::push_binders
   5: chalk_solve::clauses::builtin_traits::add_builtin_program_clauses
   6: chalk_recursive::solve::SolveIterationHelpers::solve_from_clauses
   7: chalk_recursive::recursive::<impl chalk_recursive::fixed_point::SolverStuff<chalk_ir::UCanonical<chalk_ir::InEnvironment<chalk_ir::Goal<I>>>,core::result::Result<chalk_solve::solve::Solution<I>,chalk_ir::NoSolution>> for &dyn chalk_solve::RustIrDatabase<I>>::solve_iteration
   8: chalk_recursive::fixed_point::RecursiveContext<K,V>::solve_goal
   9: chalk_recursive::fixed_point::RecursiveContext<K,V>::solve_root_goal
  10: hir_ty::traits::trait_solve_query
  11: salsa::runtime::Runtime::execute_query_implementation
  12: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  13: salsa::derived::slot::Slot<Q,MP>::read
  14: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  15: salsa::QueryTable<Q>::get
  16: <DB as hir_ty::db::HirDatabase>::trait_solve_query
  17: hir_ty::db::trait_solve_wait
  18: <DB as hir_ty::db::HirDatabase>::trait_solve
  19: hir_ty::method_resolution::iterate_trait_method_candidates
  20: hir_ty::method_resolution::iterate_method_candidates_by_receiver
  21: hir_ty::method_resolution::iterate_method_candidates_dyn
  22: hir::Type::iterate_method_candidates_dyn
  23: hir::Type::iterate_method_candidates
  24: ide_completion::completions::dot::complete_dot
  25: ide_completion::completions::complete_name_ref
  26: ide_completion::completions
  27: std::panicking::try
  28: rust_analyzer::handlers::handle_completion
  29: std::panicking::try
  30: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[Error - 2:39:37 PM] Request textDocument/completion failed.
  Message: request handler panicked: called `Option::unwrap()` on a `None` value
  Code: -32603

rust-analyzer version: rust-analyzer version: 0.3.1258-standalone

rustc version: rustc 1.66.0-nightly (6e95b6da8 2022-10-22)

relevant settings: N/A

[bjorn3]

The crash in question happens when replacing the bswap intrinsic implementation with:

        sym::bswap => {
            intrinsic_args!(fx, args => (arg); intrinsic);
            let val = arg.load_scalar(fx);

            let res = match fx.bcx.func.dfg.value_type(val) {
                types::I8 => val,
                types::I128 => {
                    // FIXME(bytecodealliance/wasmtime#1092) bswap.i128 is not yet implemented
                    let (lsb, msb) = fx.bcx.ins().isplit(val);
                    let lsb_swap = fx.bcx.ins().bswap(lsb);
                }
                _ =>  fx.bcx.ins().bswap(val),
            };
            let res = CValue::by_val(res, arg.layout());
            ret.write_cvalue(fx, res);
        }

[bjorn3]

Crashing commit: rust-lang/rustc_codegen_cranelift@0f8111a (from the update_cranelift branch)

[Absolucy]

Running into the same panic being spammed whenever I copy-paste this code into a new file: https://pastebin.com/Wnfn30SV

Panic context:
> 
version: 0.3.1309-standalone (a2beeb8db 2022-12-04)
request: textDocument/inlayHint InlayHintParams {
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    text_document: TextDocumentIdentifier {
        uri: Url {
            scheme: "file",
            cannot_be_a_base: false,
            username: "",
            password: None,
            host: None,
            port: None,
            path: "/c%3A/Users/Lucy/Documents/Code/flushify/src/app/ui/central_panel.rs",
            query: None,
            fragment: None,
        },
    },
    range: Range {
        start: Position {
            line: 2,
            character: 0,
        },
        end: Position {
            line: 133,
            character: 0,
        },
    },
}

thread 'Worker' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\chalk-solve-0.87.0\src\clauses\builtin_traits\fn_family.rs:90:20
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:584
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:142
   2: core::panicking::panic
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:48
   3: chalk_solve::clauses::builtin_traits::fn_family::add_fn_trait_program_clauses
   4: chalk_solve::clauses::builder::ClauseBuilder<I>::push_binders
   5: chalk_solve::clauses::builtin_traits::add_builtin_program_clauses
   6: chalk_recursive::solve::SolveIteration::solve_iteration
   7: chalk_recursive::solve::SolveIteration::solve_iteration
   8: chalk_recursive::fixed_point::RecursiveContext<K,V>::solve_goal
   9: <chalk_recursive::recursive::RecursiveSolver<I> as chalk_solve::solve::Solver<I>>::solve_limited
  10: <hir_ty::db::TraitSolveQueryQuery as salsa::plumbing::QueryFunction>::execute
  11: salsa::runtime::Runtime::execute_query_implementation
  12: core::ptr::drop_in_place<salsa::derived::slot::Memo<hir_ty::db::ProgramClausesForChalkEnvQuery>>
  13: salsa::derived::slot::Slot<Q,MP>::read
  14: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  15: salsa::QueryTable<Q>::get
  16: <DB as hir_ty::db::HirDatabase>::trait_solve_query
  17: hir_ty::db::trait_solve_wait
  18: <DB as hir_ty::db::HirDatabase>::trait_solve
  19: hir_ty::infer::unify::InferenceTable::register_obligation_in_env
  20: hir_ty::infer::unify::InferenceTable::resolve_obligations_as_possible
  21: hir_ty::infer::pat::<impl hir_ty::infer::InferenceContext>::infer_pat
  22: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  23: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_assignee_expr
  24: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  25: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  26: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  27: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  28: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_assignee_expr
  29: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  30: hashbrown::raw::RawTable<T,A>::find::{{closure}}
  31: hir_ty::infer::infer_query
  32: salsa::runtime::Runtime::execute_query_implementation
  33: core::ptr::drop_in_place<salsa::derived::slot::Memo<hir_ty::db::ProgramClausesForChalkEnvQuery>>
  34: salsa::derived::slot::Slot<Q,MP>::read
  35: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  36: <DB as hir_ty::db::HirDatabase>::infer_query
  37: hir_ty::db::infer_wait
  38: <DB as hir_ty::db::HirDatabase>::infer
  39: hir::source_analyzer::SourceAnalyzer::new_for_body
  40: hir::semantics::SemanticsImpl::analyze_impl
  41: ide::inlay_hints::hints
  42: ide::inlay_hints::hints
  43: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  44: ide::inlay_hints::inlay_hints
  45: std::panicking::try
  46: rust_analyzer::handlers::handle_inlay_hints
  47: std::panicking::try
  48: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[Error - 8:34:34 PM] Request textDocument/inlayHint failed.
  Message: request handler panicked: called `Option::unwrap()` on a `None` value
  Code: -32603 

[Marcono1234]

I am also experiencing this with VS Code extension version v0.3.1348.

VS Code version

Version: 1.74.2 (user setup)
Commit: e8a3071ea4344d9d48ef8a4df2c097372b0c5161
Date: 2022-12-20T10:29:14.590Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.22000
Sandboxed: No

For me it occurs occasionally when I open VS Code and a .rs file is already open from the last time I edited it in VS Code. When I then try to edit that file while rust-analyzer is still loading / indexing and save the file, any edit afterwards causes error dialogs similar to what @Absolucy showed above.

[IvanKostyuk]

Reproducible in the version v0.3.1541

VS Code version

Version: 1.78.2 (system setup)
Commit: b3e4e68a0bc097f0ae7907b217c1119af9e03435
Date: 2023-05-10T14:39:26.248Z
Electron: 22.5.2
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Windows_NT x64 10.0.19045
Sandboxed: Yes

I'm trying to autocomplete String::as_bytes()

Restarted VS Code - everything works.

[lowr]

I've tried to reproduce the crash several times only to fail. Judging from the stack trace, this panic really shouldn't happen at all, yet it happens somehow, and I'm starting to suspect this might be an issue around salsa's recomputation.

If anyone happens to get the crash reproducible, please report it here -- I'd be more than happy to investigate. Otherwise, please restart rust-analyzer and it should start working just fine again.

[lnicola]

Just ran into this on code like

Typing f32:: or String:: triggered the panic, but it stopped happening after restarting the server.

[Veykril]

I feel like this might be another chalk bug as it should not possible for this to happen (especially with a sysroot loaded)

[lnicola]

@Veykril could it be that we're hitting chalk before we've fully loaded the sysroot? I can trigger it somewhat reliably by triggering completion right after opening a project.

[Veykril]

then we should be able to reproduce this easily by setting the sysroot to null though

[lnicola]

I'm not sure. What if there's a difference between "no sysroot" and "sysroot, but not yet loaded"? I added some logging to ChalkContext::well_known_trait_id, reproduced the crash and got:

[ERROR hir_ty::chalk_db] FnOnce => None

(which seems to get cached, so it fails every time afterwards).

While a normal load yields:

[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] Fn => Some(TraitId(68))
[ERROR hir_ty::chalk_db] Fn => Some(TraitId(68))
[ERROR hir_ty::chalk_db] FnOnce => Some(TraitId(70))
[ERROR hir_ty::chalk_db] FnMut => Some(TraitId(69))
[ERROR hir_ty::chalk_db] FnMut => Some(TraitId(69))

EDIT: and of course, when it fails we know about e.g. str, but not about FnOnce, which is a harder situation to run into without a sysroot.

[Veykril]

(which seems to get cached, so it fails every time afterwards).

That sounds like we might be hitting the salsa bug here (where things are not getting properly invalidated)?

[Veykril]

Ye so looking at the source we should never be able to hit this unless there is something buggy going on. The panicking code path here can only be reached if we have successfully created the HIR trait representing the Fn* trait at which point the well_known_trait_id cannot fail as we know the trait already...