Unwrap of None panic in fold_free_var_lifetime

[rix0rrr]

The following panic happens to me in both release version and pre-release version in VSCode as soon as the analyzer needs to autocomplete anything, and nearly makes it impossible to use:

thread 'Worker' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chalk-ir-0.97.0/src/lib.rs:1455:33:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: core::option::unwrap_failed
   4: <chalk_ir::SubstFolder<I,A> as chalk_ir::fold::TypeFolder<I>>::fold_free_var_lifetime
   5: chalk_ir::fold::TypeSuperFoldable::super_fold_with
   6: chalk_ir::_::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::DynTy<I>>::try_fold_with
   7: chalk_ir::fold::TypeSuperFoldable::super_fold_with
   8: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::GenericArg<I>>::try_fold_with
   9: <core::iter::adapters::GenericShunt<I,R> as core::iter::traits::iterator::Iterator>::next
  10: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
  11: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::Substitution<I>>::try_fold_with
  12: chalk_ir::fold::TypeSuperFoldable::super_fold_with
  13: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::GenericArg<I>>::try_fold_with
  14: <core::iter::adapters::GenericShunt<I,R> as core::iter::traits::iterator::Iterator>::next
  15: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
  16: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::Substitution<I>>::try_fold_with
  17: chalk_ir::fold::TypeSuperFoldable::super_fold_with
  18: chalk_ir::_::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::WhereClause<I>>::try_fold_with
  19: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
  20: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::QuantifiedWhereClauses<I>>::try_fold_with
  21: chalk_solve::infer::instantiate::<impl chalk_solve::infer::InferenceTable<I>>::instantiate_binders_existentially
  22: <chalk_solve::infer::unify::Unifier<I> as chalk_ir::zip::Zipper<I>>::zip_binders
  23: chalk_solve::infer::unify::Unifier<I>::relate_ty_ty
  24: chalk_solve::infer::unify::Unifier<I>::relate_var_ty
  25: chalk_solve::infer::unify::Unifier<I>::relate_ty_ty
  26: <chalk_solve::infer::unify::Unifier<I> as chalk_ir::zip::Zipper<I>>::zip_tys
  27: chalk_ir::zip::Zipper::zip_substs
  28: chalk_solve::infer::unify::Unifier<I>::relate_ty_ty
  29: <chalk_solve::infer::unify::Unifier<I> as chalk_ir::zip::Zipper<I>>::zip_tys
  30: chalk_solve::infer::unify::Unifier<I>::relate
  31: chalk_solve::infer::unify::<impl chalk_solve::infer::InferenceTable<I>>::relate
  32: hir_ty::infer::unify::InferenceTable::fudge_inference
  33: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::expected_inputs_for_expected_output
  34: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  35: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  36: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  37: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_return
  38: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  39: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::check_call_arguments
  40: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::check_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_coerce
  43: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_block
  44: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  45: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_return
  46: hir_ty::infer::infer_query
  47: salsa::Cycle::catch
  48: salsa::derived::slot::Slot<Q,MP>::execute
  49: salsa::derived::slot::Slot<Q,MP>::read
  50: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::fetch
  51: <DB as hir_ty::db::HirDatabase>::infer
  52: hir::DefWithBody::diagnostics
  53: hir::Module::diagnostics
  54: ide_diagnostics::diagnostics
  55: salsa::Cancelled::catch
  56: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
  57: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
  58: rust_analyzer::diagnostics::fetch_native_diagnostics
  59: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

rust-analyzer version:

Both of these:

• 0.4.1943-standalone (49e502b 2024-04-30)
• 0.3.1940-standalone (f216be4 2024-04-27)

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

editor or extension:

Both of these:

• VSCode v0.4.1943 (pre-release)
• VSCode v0.3.1940

relevant settings: Nothing special

code snippet to reproduce: Happens on a large proprietary project, unsure what's triggering it.

[rix0rrr]

I'm not quite sure how this code can cause that panic... must be due to inlining?

    fn fold_free_var_lifetime(
        &mut self,
        bound_var: BoundVar,
        outer_binder: DebruijnIndex,
    ) -> Lifetime<I> {
        assert_eq!(bound_var.debruijn, DebruijnIndex::INNERMOST);
        let l = self.at(bound_var.index);
        let l = l.assert_lifetime_ref(TypeFolder::interner(self));
        l.clone()
            .shifted_in_from(TypeFolder::interner(self), outer_binder)
    }

https://github.com/rust-lang/chalk/blob/ee7f29968e4ce457765e4afe3ec0dbc23c4a9c07/chalk-ir/src/lib.rs#L2834

[lnicola]

I guess #17160 didn't fix this one CC @dfireBird.

[dfireBird]

Yeah, this and some stracktraces presented in #17080 seem same. I'm currently trying to fix that issue.

[dfireBird]

Hello,
A fix was pushed with PR #17190 and it was released as part of today's release (version number: 0.4.1949). Can you please test it and report whether the issue is fixed for you or not? Thanks.

[rix0rrr]

Hard to say, I'm now running into this: #16376

EDIT: well wait. On the beta channel so far it seems to be better, but I've only given it a couple minutes so far.