Change:
// `tests/ui/closures/2229_closure_analysis/preserve_field_drop_order.rs`. for (_, captures) in &mut root_var_min_capture_list { captures.sort_by(|capture1, capture2| { <del> for (p1, p2) in capture1.place.projections.iter().zip(&capture2.place.projections) { </del> <ins> fn is_field<'a>(p: &&Projection<'a>) -> bool { match p.kind { ProjectionKind::Field(_, _) => true, ProjectionKind::Deref | ProjectionKind::OpaqueCast => false, p @ (ProjectionKind::Subslice | ProjectionKind::Index) => { bug!("ProjectionKind {:?} was unexpected", p) } } } // Need to sort only by Field projections, so filter away others. // A previous implementation considered other projection types too // but that caused ICE #118144 let capture1_field_projections = capture1.place.projections.iter().filter(is_field); let capture2_field_projections = capture2.place.projections.iter().filter(is_field); for (p1, p2) in capture1_field_projections.zip(capture2_field_projections) { </ins> // We do not need to look at the `Projection.ty` fields here because at each // step of the iteration, the projections will either be the same and therefore // the types must be as well or the current projection will be different and // we will return the result of comparing the field indexes. match (p1.kind, p2.kind) { <del> // Paths are the same, continue to next loop. (ProjectionKind::Deref, ProjectionKind::Deref) => {} (ProjectionKind::OpaqueCast, ProjectionKind::OpaqueCast) => {} (ProjectionKind::Field(i1, _), ProjectionKind::Field(i2, _)) if i1 == i2 => {} // Fields are different, compare them. </del> (ProjectionKind::Field(i1, _), ProjectionKind::Field(i2, _)) => { <del> return i1.cmp(&i2); </del> <ins> // Compare only if paths are different. // Otherwise continue to the next iteration if i1 != i2 { return i1.cmp(&i2); } </ins> } <del> // We should have either a pair of `Deref`s or a pair of `Field`s. // Anything else is a bug. ( l @ (ProjectionKind::Deref | ProjectionKind::Field(..)), r @ (ProjectionKind::Deref | ProjectionKind::Field(..)), ) => bug!( "ProjectionKinds Deref and Field were mismatched: ({:?}, {:?})", l, r ), ( l @ (ProjectionKind::Index | ProjectionKind::Subslice | ProjectionKind::Deref | ProjectionKind::OpaqueCast | ProjectionKind::Field(..)), r @ (ProjectionKind::Index | ProjectionKind::Subslice | ProjectionKind::Deref | ProjectionKind::OpaqueCast | ProjectionKind::Field(..)), ) => bug!( "ProjectionKinds Index or Subslice were unexpected: ({:?}, {:?})", l, r ), </del> <ins> // Given the filter above, this arm should never be hit (l, r) => bug!("ProjectionKinds {:?} or {:?} were unexpected", l, r), </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: ProjectionKinds Deref and Field were mismatched: (Deref, Field(0, 0))', 'error: internal compiler error: ProjectionKinds Deref and Field were mismatched: (Deref, Field(0, 0))' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. .

--&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --&lt;!-- TRIAGEBOTSTART --&lt;!-- TRIAGEBOTASSIGNSTART --&lt;!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --&lt;!-- TRIAGEBOTASSIGNEND --&lt;!-- TRIAGEBOTEND --
smaller
Regression in nightly-2022-11-06 commit[0] 2022-11-04: Auto merge of - matthiaskrgr:rollup-iym9kmg, r=matthiaskrgr commit[1] 2022-11-04: Auto merge of - ferrocene:pa-compile-flags-last, r=jyn514 commit[2] 2022-11-05: Auto merge of - matthiaskrgr:rollup-tj53nte, r=matthiaskrgr commit[3] 2022-11-05: Auto merge of - weihanglo:update-cargo, r=weihanglo commit[4] 2022-11-05: Auto merge of - Dylan-DPC:rollup-2nbmtc9, r=Dylan-DPC commit[5] 2022-11-05: Auto merge of - michaelwoerister:consistent-slice-and-str-cpp-like-debuginfo-names, r=wesleywiser commit[6] 2022-11-05: Auto merge of - chenyukang:yukang/fix--ice, r=nagisa commit[7] 2022-11-05: Auto merge of - matthiaskrgr:rollup-k8i0j9m, r=matthiaskrgr commit[8] 2022-11-05: Auto merge of - JohnTitor:stabilize-instruction-set, r=oli-obk ERROR: no CI builds available between and within last 167 days
claim
The above bisection may be wrong.

I got this instead: Regression in nightly-2021-09-26 found 9 bors merge commits in the specified range commit[0] 2021-09-24: Auto merge of - petrochenkov:getmod2, r=cjgillot commit[1] 2021-09-24: Auto merge of - FabianWolff:issue-, r=estebank commit[2] 2021-09-25: Auto merge of - workingjubilee:rollup-1swktdq, r=workingjubilee commit[3] 2021-09-25: Auto merge of - petrochenkov:derivecfglimit2, r=Aaron1011 commit[4] 2021-09-25: Auto merge of - BoxyUwU:trackersMcCaller, r=eddyb commit[5] 2021-09-25: Auto merge of - nbdd0121:box2, r=jonas-schievink commit[6] 2021-09-25: Auto merge of - nikic:newpm-2, r=nagisa commit[7] 2021-09-25: Auto merge of - adamgemmell:dev/asm-tests, r=Amanieu commit[8] 2021-09-25: Auto merge of - steffahn:fixcodespacing, r=jyn514 ERROR: no CI builds available between and within last 167 days The issue seems to be present since PR which is part of the rollup
The ICE originates at the below code in the function : This code expects that all the captures of a given variable should have projection sequences that adhere to the following rules: contain only , or projection kinds ( and are not allowed) all should have the exact same sequence e.g. : and : are okay but : and : are not acceptable. What causes the below snippet to ICE: is that receives the following projection sequences for the arg : : : where comes from the statement and comes from the statement As these captures violate rule 2 above, an ICE ensues. The code that is ICEing was introduced PR and has been ICEing ever since.
As for the fix, I feel there's little we can do to make these two captures: : : align with each other as per rule 2.

A statement like this , which is destructuring into an previously declared variable , always results in a single projection while always results in a projection sequence. (Worth noting that if we change to , i.e. we declare the variable while destructuring, then the ICE goes away. This is because results in a projection sequence which does not violate rule 2.) A simple fix in my view would be to remove rule 2 and allow projection sequences like and to co-exist. We will just have figure out how to sort them w.r.t. each other. Wonder if just removing all s from the projection sequences before comparing them could work. might be able to shed some light.