Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

var_universe invoked on bound variable when analysis-stating --with-deps #5495

Closed
matklad opened this issue Jul 22, 2020 · 7 comments · Fixed by rust-lang/chalk#649
Closed
Labels
A-ty type system / type inference / traits / method resolution

Comments

@matklad
Copy link
Member

matklad commented Jul 22, 2020

Haven't tried to minimize this yet, but I don't think I've seen an error quite like this before:

λ cargo run --release -p rust-analyzer --bin rust-analyzer -- analysis-stats . --parallel --memory-usage --with-deps
    Finished release [optimized] target(s) in 0.08s
     Running `target/release/rust-analyzer analysis-stats . --parallel --memory-usage --with-deps`
Database loaded 220.177388ms
Crates in this dir: 626
Total modules found: 3880
Total declarations: 147599
Total functions: 70523
Item Collection: 20.22729142s, 857mb allocated 0b resident
thread '<unnamed>' panicked at 'var_universe invoked on bound variable', /home/matklad/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/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::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:526
  11: std::panicking::begin_panic
  12: chalk_solve::infer::unify::Unifier<I>::unify_ty_ty
  13: <chalk_ir::Substitution<I> as chalk_ir::zip::Zip<I>>::zip_with
  14: chalk_solve::infer::unify::Unifier<I>::unify_ty_ty
  15: chalk_ir::_DERIVE_chalk_ir_zip_Zip_I_FOR_DomainGoal::<impl chalk_ir::zip::Zip<I> for chalk_ir::DomainGoal<I>>::zip_with
  16: chalk_solve::infer::unify::<impl chalk_solve::infer::InferenceTable<I>>::unify
  17: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::new_with_clause
  18: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  19: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  20: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::prove
  21: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::solve
  22: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  23: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  24: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::prove
  25: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::solve
  26: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  27: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  28: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::prove
  29: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::solve
  30: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  31: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  32: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::prove
  33: chalk_recursive::fulfill::Fulfill<I,Solver,Infer>::solve
  34: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  35: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  36: <chalk_recursive::recursive::RecursiveSolver<I> as chalk_solve::solve::Solver<I>>::solve_limited
  37: ra_hir_ty::traits::trait_solve_query
  38: salsa::runtime::Runtime::execute_query_implementation
  39: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  40: salsa::derived::slot::Slot<Q,MP>::read
  41: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  42: <DB as ra_hir_ty::db::HirDatabase>::trait_solve::__shim
  43: <DB as ra_hir_ty::db::HirDatabase>::trait_solve
  44: ra_hir_ty::infer::InferenceContext::resolve_ty_as_possible
  45: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_coerce
  46: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
  47: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_coerce
  48: ra_hir_ty::infer::infer_query
  49: salsa::runtime::Runtime::execute_query_implementation
  50: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  51: salsa::derived::slot::Slot<Q,MP>::read
  52: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  53: <DB as ra_hir_ty::db::HirDatabase>::infer_query::__shim
  54: ra_hir_ty::db::infer_wait
  55: core::ops::function::impls::<impl core::ops::function::Fn<A> for &F>::call
  56: <rayon::iter::sum::SumFolder<S> as rayon::iter::plumbing::Folder<T>>::consume_iter
  57: rayon::iter::plumbing::bridge_producer_consumer::helper
  58: rayon_core::registry::in_worker
  59: rayon::iter::plumbing::bridge_producer_consumer::helper
  60: rayon_core::registry::in_worker
  61: rayon::iter::plumbing::bridge_producer_consumer::helper
  62: rayon_core::registry::in_worker
  63: rayon::iter::plumbing::bridge_producer_consumer::helper
  64: rayon_core::registry::in_worker
  65: rayon::iter::plumbing::bridge_producer_consumer::helper
  66: rayon_core::registry::in_worker
  67: rayon::iter::plumbing::bridge_producer_consumer::helper
  68: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
  69: rayon_core::registry::WorkerThread::wait_until_cold
  70: rayon_core::registry::ThreadBuilder::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

cc @flodiebold

@matklad
Copy link
Member Author

matklad commented Jul 22, 2020

Seems like we need to add --with-deps to our CI

@flodiebold flodiebold added the A-ty type system / type inference / traits / method resolution label Jul 22, 2020
@detrumi
Copy link
Member

detrumi commented Jul 28, 2020

Going wrong here.

Minimized:

fn main() {
    let a: Vec<(i32, i32)> = (0..10).map(|i| (i, i)).collect();
}

@matklad
Copy link
Member Author

matklad commented Jul 28, 2020

Nice minimization, thanks @detrumi!

flodiebold added a commit to flodiebold/chalk that referenced this issue Nov 6, 2020
This should fix rust-lang/rust-analyzer#5495.

`unify_ty_ty` calls `normalize_ty_shallow` on both types and then assumes that
they can't be bound variables. With integer type variables, this assumption was
broken, because you could have a general type variable resolving to an integer
type variable resolving to i32. To fix this, `normalize_ty_shallow` probes
twice, to make sure to fully resolve the variable.
@flodiebold
Copy link
Member

Found it, the minimization was helpful. It's a bug in Chalk's unification logic.

bors added a commit to rust-lang/chalk that referenced this issue Nov 8, 2020
… r=jackh726

Fix "var_universe invoked on bound variable" crash

This should fix rust-lang/rust-analyzer#5495.

`unify_ty_ty` calls `normalize_ty_shallow` on both types and then assumes that they can't be bound variables. With integer type variables, this assumption was broken, because you could have a general type variable resolving to an integer type variable resolving to i32. To fix this, `normalize_ty_shallow` probes twice, to make sure to fully resolve the variable.
@lnicola
Copy link
Member

lnicola commented Dec 1, 2020

@flodiebold is this fixed?

@flodiebold
Copy link
Member

In Chalk yes, but we don't have that Chalk version yet.

@flodiebold
Copy link
Member

Should be fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ty type system / type inference / traits / method resolution
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants