subst.rs "index out of bounds: the len is 1 but the index is 1"

[jpetkau]

This is with rust-analyzer using the vscode client on Windows.

I get this error frequently:

thread '<unnamed>' panicked at 'index out of bounds: the len is 1 but the index is 1', 
C:\Users\runneradmin\.cargo\registry\src\gb.xjqchip.workers.dev-1ecc6299db9ec823\chalk-ir-0.69.0\src\fold\subst.rs:58:19
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Unfortunately I don't have an easy repro. It happens after I've been working in the project for a while (in multiple different projects), and once it happens the server is effectively dead (just keeps repeating this error). Restarting vscode and/or rust-analyzer does not fix it, but cargo clean does. [Edit: that was true of similar problems I've run into, but this particular example seems to reproduce reliably and is unaffected by cargo clean.]

If there's some way I can get better diagnostic info to help debug it I'd be glad to do that, but I can't even seem to get RUST_BACKTRACE to work. I have RUST_BACKTRACE=full set in both my system environment variables and via setting "rust-analyzer.server.extraEnv": {"RUST_BACKTRACE": "full"}, but I still get the short panic message as shown above.

(I don't think this is a dup of #5366 since the error location is different.)

[jpetkau]

Ok, I have a small repro in github. If I load this project in vscode on Windows, open the "lib.rs" file, and wait a few seconds, I get the error consistently.

(The repro uses a peg parser macro. I tried replacing the code with the result of cargo +nightly rustc -Z unstable-options --pretty=expanded but the error doesn't happen when I do that.)

[jpetkau]

More update:

• Running %APPDATA%\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-x86_64-pc-windows-msvc.exe diagnostics . from that project folder also reproduces the error, so you don't need vscode.
• RUST_BACKTRACE still doesn't work, even though I'm now running the executable myself.

[jpetkau]

More more update: it repros on Linux (using the version in rustup +nightly component add rust-analyzer-preview), and backtrace works there:

0: rust_begin_unwind
            at /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:515:5
1: core::panicking::panic_fmt
            at /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/panicking.rs:92:14
2: core::panicking::panic_bounds_check
            at /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/panicking.rs:69:5
3: <chalk_ir::fold::subst::Subst<I> as chalk_ir::fold::Folder<I>>::fold_free_var_ty
4: <chalk_ir::Ty<I> as chalk_ir::fold::SuperFold<I>>::super_fold_with
5: <chalk_ir::Ty<I> as chalk_ir::fold::SuperFold<I>>::super_fold_with
6: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::Fold<I> for chalk_ir::GenericArg<I>>::fold_with
7: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
8: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::Fold<I> for chalk_ir::Substitution<I>>::fold_with
9: <chalk_ir::Ty<I> as chalk_ir::fold::SuperFold<I>>::super_fold_with
10: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::Fold<I> for chalk_ir::GenericArg<I>>::fold_with
11: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
12: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::Fold<I> for chalk_ir::Substitution<I>>::fold_with
13: chalk_ir::_DERIVE_chalk_ir_fold_Fold_I_FOR_WhereClause::<impl chalk_ir::fold::Fold<I> for chalk_ir::WhereClause<I>>::fold_with
14: chalk_ir::fold::binder_impls::<impl chalk_ir::fold::Fold<I> for chalk_ir::Binders<T>>::fold_with
15: <chalk_ir::cast::Casted<IT,U> as core::iter::traits::iterator::Iterator>::next
16: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
17: <hir_ty::interner::Interner as chalk_ir::interner::Interner>::intern_quantified_where_clauses
18: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::Fold<I> for chalk_ir::QuantifiedWhereClauses<I>>::fold_with
19: chalk_solve::infer::instantiate::<impl chalk_solve::infer::InferenceTable<I>>::instantiate_binders_universally
20: <chalk_solve::infer::unify::Unifier<I> as chalk_ir::zip::Zipper<I>>::zip_binders
21: chalk_solve::infer::unify::Unifier<I>::relate_ty_ty
22: chalk_solve::infer::unify::Unifier<I>::relate_var_ty
23: chalk_solve::infer::unify::Unifier<I>::relate_ty_ty
24: <chalk_solve::infer::unify::Unifier<I> as chalk_ir::zip::Zipper<I>>::zip_tys
25: chalk_ir::zip::Zipper::zip_substs
26: chalk_ir::_DERIVE_chalk_ir_zip_Zip_I_FOR_WhereClause::<impl chalk_ir::zip::Zip<I> for chalk_ir::WhereClause<I>>::zip_with
27: chalk_solve::infer::unify::Unifier<I>::relate
28: chalk_solve::infer::unify::<impl chalk_solve::infer::InferenceTable<I>>::relate
29: chalk_recursive::fulfill::Fulfill<I,Solver>::new_with_clause
30: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
31: <chalk_recursive::recursive::RecursiveSolver<I> as chalk_solve::solve::Solver<I>>::solve_limited
32: hir_ty::traits::trait_solve_query
33: salsa::runtime::Runtime::execute_query_implementation
34: salsa::derived::slot::Slot<Q,MP>::read_upgrade
35: salsa::derived::slot::Slot<Q,MP>::read
36: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
37: salsa::QueryTable<Q>::get
38: <DB as hir_ty::db::HirDatabase>::trait_solve_query::__shim
39: <DB as hir_ty::db::HirDatabase>::trait_solve_query
40: hir_ty::db::trait_solve_wait
41: <DB as hir_ty::db::HirDatabase>::trait_solve
42: hir_ty::infer::coerce::<impl hir_ty::infer::InferenceContext>::coerce_inner
43: hir_ty::infer::coerce::<impl hir_ty::infer::InferenceContext>::coerce
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_inner
46: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
47: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::check_call_arguments
48: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
49: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
50: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_block
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_block
54: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
55: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
56: hir_ty::infer::infer_query
57: salsa::runtime::Runtime::execute_query_implementation
58: salsa::derived::slot::Slot<Q,MP>::read_upgrade
59: salsa::derived::slot::Slot<Q,MP>::read
60: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
61: <DB as hir_ty::db::HirDatabase>::infer_query::__shim
62: hir_ty::db::infer_wait
63: hir::Function::diagnostics
64: hir::Module::diagnostics
65: hir::Module::diagnostics
66: ide_diagnostics::diagnostics
67: ide::Analysis::diagnostics
68: rust_analyzer::cli::diagnostics::diagnostics
69: rust_analyzer::main

[lnicola]

Minimized test case:

fn infix_parse<T, S>(_state: S, _level_code: &Fn(S)) -> T {
    todo!()
}

fn parse_arule() {
    infix_parse((), &(|_recurse| ()))
}

Interestingly, it doesn't happen with &dyn Fn.

[flodiebold]

Interestingly, it doesn't happen with &dyn Fn.

That is interesting. Might be a problem with the lowering code then.

Bare traits get lowered here:
https://github.com/rust-analyzer/rust-analyzer/blob/444679f202742c8fd00e9d1c7fddfaa9a067e640/crates/hir_ty/src/lower.rs#L439-L451

Whereas dyn Trait gets lowered here:
https://github.com/rust-analyzer/rust-analyzer/blob/444679f202742c8fd00e9d1c7fddfaa9a067e640/crates/hir_ty/src/lower.rs#L205-L216

Might be instructive to create a test for this and compare the lowered types.

Edit: The bare trait code also doesn't seem to be handling assoc type bindings? 🤔

[lnicola]

--- bare
+++ dyn
@@ -1,4 +1,4 @@
-[WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(60)<1<[?0 := !0_0]>>)] + 'static
+[WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(60)<1<[?0 := !0_0]>>), for<> AliasEq(AliasTy(?) = 0<[]>)] + 'static
 [WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(71))] + 'static
 [WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(71)), for<> Implemented(^1.0: TraitId(24))] + 'static
 [WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(71)), for<> Implemented(^1.0: TraitId(24)), for<> Implemented(^1.0: TraitId(30))] + 'static
@@ -24,4 +24,4 @@
 [WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(175))] + 'static
 [WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(175)), for<> Implemented(^1.0: TraitId(24))] + 'static
 [WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(175)), for<> Implemented(^1.0: TraitId(24)), for<> Implemented(^1.0: TraitId(30))] + 'static
-[WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(60)<1<[?0 := ^1.1]>>)] + 'static
+[WARN hir_ty::lower] dyn for<type> [for<> Implemented(^1.0: TraitId(60)<1<[?0 := ^2.1]>>), for<> AliasEq(AliasTy(?) = 0<[]>)] + 'static

[flodiebold]

Yeah, so we drop the associated type bindings (bad, but not the cause of the crash), and we mess up the binders (the 2 vs. 1 in the second difference).

[lnicola]

@flodiebold feel free to look into this, I tried some random combinations of shifting the binders, but failed miserably.

[flodiebold]

I can look into it next week probably, but my current guess would be wrapping the lower_trait_ref_from_resolved_path call in a with_shifted_in similarly to the dyn case. Unless that's one of the things you already tried ;)

[lnicola]

Doing only that fixes this case, but introduces other panics ("unexpected free variable with depth ^0.0 with outer binder ^0").