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

fix: treat enum variants as generic item on their own #13339

Merged
merged 1 commit into from
Oct 3, 2022

Conversation

lowr
Copy link
Contributor

@lowr lowr commented Oct 3, 2022

Fixup for #13335

It turns out I tried to merge two procedures into one utility function without noticing the incompatibility.

This time I did run analysis-stats on the four crates and confirmed it doesn't crash and this patch doesn't cause regression.

@Veykril
Copy link
Member

Veykril commented Oct 3, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Oct 3, 2022

📌 Commit e0a161b has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Oct 3, 2022

⌛ Testing commit e0a161b with merge 974caaf...

@bors
Copy link
Contributor

bors commented Oct 3, 2022

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 974caaf to master...

@bors bors merged commit 974caaf into rust-lang:master Oct 3, 2022
@Veykril
Copy link
Member

Veykril commented Oct 4, 2022

Looks like there is still something wrong after this fix, analysis-stats works fine on r-a, but not on the std library it seems?

Run target/x86_64-unknown-linux-gnu/release/rust-analyzer analysis-stats --with-deps $(rustc --print sysroot)/lib/rustlib/src/rust/library/std
Failed to create perf counter: Operation not permitted (os error 1)
Failed to create perf counter: Operation not permitted (os error 1)
Database loaded:     19.00s (metadata 1.38s; build 17.51s)
Failed to create perf counter: Operation not permitted (os error 1)
  crates: 35, mods: 1252, decls: 39416, fns: 26420
Item Collection:     7.95s
Failed to create perf counter: Operation not permitted (os error 1)
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /github/home/.cargo/registry/src/github.com-1ecc6299db9ec823/chalk-ir-0.84.0/src/lib.rs:1457:33
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_ir::SubstFolder<I,A> as chalk_ir::fold::TypeFolder<I>>::fold_free_var_const
   4: <chalk_ir::Const<I> as chalk_ir::fold::TypeSuperFoldable<I>>::super_fold_with
   5: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::GenericArg<I>>::fold_with
   6: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
   7: <hir_ty::interner::Interner as chalk_ir::interner::Interner>::intern_substitution
   8: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::Substitution<I>>::fold_with
   9: <chalk_ir::Ty<I> as chalk_ir::fold::TypeSuperFoldable<I>>::super_fold_with
  10: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<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: <hir_ty::interner::Interner as chalk_ir::interner::Interner>::intern_substitution
  13: chalk_ir::fold::boring_impls::<impl chalk_ir::fold::TypeFoldable<I> for chalk_ir::Substitution<I>>::fold_with
  14: hir_ty::lower::named_associated_type_shorthand_candidates::{{closure}}
  15: hir_ty::lower::TyLoweringContext::lower_ty_relative_path
  16: hir_ty::lower::TyLoweringContext::lower_partly_resolved_path
  17: hir_ty::lower::TyLoweringContext::lower_ty_ext
  18: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
  19: core::iter::adapters::try_process
  20: hir_ty::lower::TyLoweringContext::lower_ty_ext
  21: hir_ty::lower::TyLoweringContext::substs_from_path_segment
  22: hir_ty::lower::TyLoweringContext::lower_trait_ref_from_path
  23: hir_ty::lower::TyLoweringContext::lower_type_bound
  24: hir_ty::lower::TyLoweringContext::lower_where_predicate
  25: hir_ty::lower::trait_environment_query
  26: salsa::runtime::Runtime::execute_query_implementation
  27: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  28: salsa::derived::slot::Slot<Q,MP>::read
  29: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  30: <DB as hir_ty::db::HirDatabase>::trait_environment::__shim
  31: <DB as hir_ty::db::HirDatabase>::trait_environment
  32: hir_ty::infer::infer_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: <DB as hir_ty::db::HirDatabase>::infer_query::__shim
  38: <DB as hir_ty::db::HirDatabase>::infer_query
  39: hir_ty::db::infer_wait
  40: rust_analyzer::cli::analysis_stats::<impl rust_analyzer::cli::flags::AnalysisStats>::run_inference
  41: rust_analyzer::cli::analysis_stats::<impl rust_analyzer::cli::flags::AnalysisStats>::run
  42: rust_analyzer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@lowr
Copy link
Contributor Author

lowr commented Oct 4, 2022

@Veykril Thanks for notifying, I'm working on the fix.

bors added a commit that referenced this pull request Oct 4, 2022
fix: use `BoundVar`s from current generic scope

Fixup for #13335, addresses #13339 (comment)

Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.
bors added a commit that referenced this pull request Oct 4, 2022
fix: use `BoundVar`s from current generic scope

Fixup for #13335, addresses #13339 (comment)

Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.
bors added a commit that referenced this pull request Oct 4, 2022
fix: use `BoundVar`s from current generic scope

Fixup for #13335, addresses #13339 (comment)

Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.
bors added a commit that referenced this pull request Oct 4, 2022
fix: use `BoundVar`s from current generic scope

Fixup for #13335, addresses #13339 (comment)

Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants