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, std::alloc::Global] thread 'rustc' panicked at 'Box', /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: ::fold_ty 8: rustc_middle::ty::fold::TypeFoldable::fold_with 9: rustc_middle::ty::structural_impls::::super_fold_with 10: as core::iter::traits::iterator::Iterator>::next 11: as alloc::vec::spec_from_iter::SpecFromIter>::from_iter 12: rustc_ty_utils::needs_drop::adt_significant_drop_tys 13: rustc_query_system::dep_graph::graph::DepGraph::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::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::::has_significant_drop 23: rustc_typeck::check::upvar::::analyze_closure 24: ::visit_expr 25: rustc_hir::intravisit::walk_expr 26: ::visit_expr 27: rustc_hir::intravisit::walk_expr 28: ::visit_expr 29: rustc_hir::intravisit::walk_expr 30: ::visit_expr 31: rustc_infer::infer::InferCtxtBuilder::enter 32: rustc_typeck::check::typeck 33: rustc_query_system::dep_graph::graph::DepGraph::with_task 34: rustc_data_structures::stack::ensure_sufficient_stack 35: rustc_query_system::query::plumbing::try_execute_query 36: ::typeck 37: rustc_typeck::check::typeck 38: rustc_query_system::dep_graph::graph::DepGraph::with_task 39: rustc_data_structures::stack::ensure_sufficient_stack 40: rustc_query_system::query::plumbing::try_execute_query 41: ::typeck 42: 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::with_task 46: rustc_data_structures::stack::ensure_sufficient_stack 47: rustc_query_system::query::plumbing::try_execute_query 48: ::typeck_item_bodies 49: rustc_session::utils::::time 50: rustc_typeck::check_crate 51: rustc_interface::passes::analysis 52: rustc_query_system::dep_graph::graph::DepGraph::with_task 53: rustc_data_structures::stack::ensure_sufficient_stack 54: rustc_query_system::query::plumbing::try_execute_query 55: ::analysis 56: rustc_interface::passes::QueryContext::enter 57: rustc_interface::queries::::enter 58: rustc_span::with_source_map 59: scoped_tls::ScopedKey::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

[lqd]

It's very similar to the previous one, and the other reductions from similar issues:

pub struct Graph<N, E, Ix> {
    _edges: E,
    _nodes: N,
    _ix: Vec<Ix>,
}
fn graph<N, E>() -> Graph<N, E, i32> {
    todo!()
}
fn main() {
    let g = graph::<i32, i32>();
    let _ = || g;
}

[JakobDegen]

@arora-aman I had started looking into #90140 and was about to claim it before realizing this one had been claimed; apologies, did not mean to step on any toes. I have not written any code yet, so hopefully we shouldn't be doing duplicate work; I'll leave my results here and either you or I (or someone else) can implement a fix, however you like.

I believe the issue is https://github.com/rust-lang/rust/blob/a3f7c4db0373aa077f86cdd1bf11122845d3b65a/compiler/rustc_ty_utils/src/needs_drop.rs#L150 which incorrectly assumes the values returned from (self.adt_components)(adt_def, substs) still need a .subst() call. This assumption is indeed correct if that call returns the fields of the ADT (as it does if the ADT is !Drop) but wrong if the call returns the generic params of the ADT (as it does if it is insignificant Drop). That should be the cause of both this issue, #90140 , and #90169 .

[arora-aman]

Thank you for looking into this :)

@JakobDegen that's about what I was thinking. I haven't written any code yet, so if you have time please go ahead and implement the fix, sooner this gets fixed the better!

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high

[camelid]

@ehuss should this issue be un-pinned now that it's fixed? Or is it still pinned to track backporting?

[ehuss]

I think it will be fine to keep it up for a while, as it is still an issue on stable which is what I expect most people are using.

[camelid]

I think it will be fine to keep it up for a while, as it is still an issue on stable which is what I expect most people are using.

Ah, I think I see: you have it pinned so people won't file duplicates. Makes sense 👍

[EwoutH]

The current milestone under which this issue is listed is 1.56.0, but it only got fixed in #90218 for 1.57.0. Can the milestone of this issue be updated to 1.57.0?

[ehuss]

Generally we use the milestone in issues for when the regression appeared (or more like "which release should we consider this for"). The PRs that resolve an issue get tagged with the release where the issue actually gets fixed (not including backports). Usually we don't retroactively change the milestone for closed issues.

I'm going to unpin this issue as I think it has been up for sufficiently long.