2021 `cargo fix --edition` ICE: type parameter out of range when substituting

[barakplasma]

Encountered while running
RUST_BACKTRACE=1 cargo +nightly fix --edition for frawk (on this specific/latest commit): https://github.com/ezrosent/frawk/tree/401fc14498c72187037a7e42fc3f2b607137ec0a

Code

Since this happened in a dependency of the project I'm building, I am not sure which line of code led to this issue.

Meta

Happens on +nightly or without +nightly
rustc +nightly --version --verbose:

rustc 1.58.0-nightly (1f12ac872 2021-10-17)
binary: rustc
commit-hash: 1f12ac87296ac61ec002e0243e7ad5a50364da35
commit-date: 2021-10-17
host: x86_64-apple-darwin
release: 1.58.0-nightly
LLVM version: 13.0.0

Error output

error: internal compiler error: compiler/rustc_middle/src/ty/subst.rs:534:17: type parameter `Ix/#3` (Ix/3) out of range when substituting, substs=[petgraph::graph::Edge<E, Ix>, std::alloc::Global]

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/1f12ac87296ac61ec002e0243e7ad5a50364da35/compiler/rustc_errors/src/lib.rs:1092:9

Backtrace

note: Switching to Edition 2021 will enable the use of the version 2 feature resolver in Cargo.
This may cause some dependencies to be built with fewer features enabled than previously.
More information about the resolver changes may be found at https://doc.rust-lang.org/nightly/edition-guide/rust-2021/default-cargo-resolver.html
When building the following dependencies, the given features will no longer be used:

  hashbrown v0.9.0 (as host dependency) removed features: ahash, default, inline-more
  indexmap v1.6.0 (as host dependency) removed features: std
  lalrpop-util v0.19.6 removed features: lexer, regex

    Checking frawk v0.4.4 (/Users/smichael1/Documents/projects/frawk)
   Migrating src/main.rs from 2018 edition to 2021
   Migrating tests/misc.rs from 2018 edition to 2021
   Migrating tests/nawk_p.rs from 2018 edition to 2021
   Migrating tests/sort.rs from 2018 edition to 2021
error: internal compiler error: compiler/rustc_middle/src/ty/subst.rs:534:17: type parameter `Ix/#3` (Ix/3) out of range when substituting, substs=[petgraph::graph::Edge<E, Ix>, std::alloc::Global]

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/1f12ac87296ac61ec002e0243e7ad5a50364da35/compiler/rustc_errors/src/lib.rs:1092:9
stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::span_bug
   3: rustc_errors::Handler::span_bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::span_bug_fmt
   7: <rustc_middle::ty::subst::SubstFolder as rustc_middle::ty::fold::TypeFolder>::fold_ty
   8: rustc_middle::ty::fold::TypeFoldable::fold_with
   9: rustc_middle::ty::structural_impls::<impl rustc_middle::ty::fold::TypeFoldable for &rustc_middle::ty::TyS>::super_fold_with
  10: <rustc_ty_utils::needs_drop::NeedsDropTypes<F> as core::iter::traits::iterator::Iterator>::next
  11: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
  12: rustc_ty_utils::needs_drop::adt_significant_drop_tys
  13: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  14: rustc_data_structures::stack::ensure_sufficient_stack
  15: rustc_query_system::query::plumbing::try_execute_query
  16: rustc_query_system::query::plumbing::get_query
  17: rustc_ty_utils::needs_drop::has_significant_drop_raw
  18: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  19: rustc_data_structures::stack::ensure_sufficient_stack
  20: rustc_query_system::query::plumbing::try_execute_query
  21: rustc_query_system::query::plumbing::get_query
  22: rustc_middle::ty::util::<impl rustc_middle::ty::TyS>::has_significant_drop
  23: rustc_typeck::check::upvar::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::analyze_closure
  24: <rustc_typeck::check::upvar::InferBorrowKindVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  25: rustc_hir::intravisit::walk_expr
  26: <rustc_typeck::check::upvar::InferBorrowKindVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  27: rustc_hir::intravisit::walk_expr
  28: <rustc_typeck::check::upvar::InferBorrowKindVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  29: rustc_hir::intravisit::walk_expr
  30: <rustc_typeck::check::upvar::InferBorrowKindVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  31: rustc_infer::infer::InferCtxtBuilder::enter
  32: rustc_typeck::check::typeck
  33: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  34: rustc_data_structures::stack::ensure_sufficient_stack
  35: rustc_query_system::query::plumbing::try_execute_query
  36: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
  37: rustc_typeck::check::typeck
  38: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  39: rustc_data_structures::stack::ensure_sufficient_stack
  40: rustc_query_system::query::plumbing::try_execute_query
  41: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
  42: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  43: rustc_data_structures::sync::par_for_each_in
  44: rustc_typeck::check::typeck_item_bodies
  45: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  46: rustc_data_structures::stack::ensure_sufficient_stack
  47: rustc_query_system::query::plumbing::try_execute_query
  48: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
  49: rustc_session::utils::<impl rustc_session::session::Session>::time
  50: rustc_typeck::check_crate
  51: rustc_interface::passes::analysis
  52: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  53: rustc_data_structures::stack::ensure_sufficient_stack
  54: rustc_query_system::query::plumbing::try_execute_query
  55: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  56: rustc_interface::passes::QueryContext::enter
  57: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  58: rustc_span::with_source_map
  59: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.58.0-nightly (1f12ac872 2021-10-17) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 -C incremental -C target-cpu=native

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [adt_significant_drop_tys] computing when `petgraph::graph_impl::Graph` has a significant destructor
#1 [has_significant_drop_raw] computing whether `petgraph::graph_impl::Graph<(), ()>` has a significant drop
#2 [typeck] type-checking `dom::test::make_cfg_impl`
#3 [typeck] type-checking `dom::test::make_cfg_impl::{closure#0}`
#4 [typeck_item_bodies] type-checking all item bodies
#5 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `frawk`

[ehuss]

cc @rust-lang/wg-rfc-2229 ICE in adt_significant_drop_tys

[ehuss]

Here is a relatively smaller reproduction using the im-rc dependency:

#![warn(rust_2021_incompatible_closure_captures)]

pub fn graph(activations: Vec<String>) -> im_rc::OrdMap<String, String> {
    let mut graph = im_rc::OrdMap::new();
    activations.iter().for_each(|r| {
        graph.entry(r.clone()).or_insert_with(String::new);
    });
    graph
}

It's a bit tricky to remove im_rc, as those types have a large number of recursive generic types (via typenum).

[lqd]

I lost track of whether my reduction still compiled while reducing petgraph and reproducing this error, but since it's pretty small I thought I'd post it anyways.

pub struct Graph<N, E, Ix> {
    nodes: Vec<N>,
    edges: Vec<E>,
    ix: Vec<Ix>,
}
fn graph<N, E>() -> Graph<N, E, u32> {
    todo!()
}
fn main() {
    let g = graph();
    || g.hello()
}

I'll see if I can reduce petgraph again, while keeping things compiling this time, so that using cargo fix is more realistic, but I suspect it may also look like #90140, and that is already pretty small.

[arora-aman]

Looks like there is also #90141. I'll try investigate these tonight.

@rustbot claim