Change:
// Depending on the implentation of `adt_has_dtor`, it is used to check if the // ADT has a destructor or if the ADT only has a significant destructor. For // understanding significant destructor look at `adt_significant_drop_tys`. <del> fn adt_drop_tys_helper<'tcx>( </del> <ins> fn drop_tys_helper<'tcx>( </ins> tcx: TyCtxt<'tcx>, <del> def_id: DefId, </del> <ins> ty: Ty<'tcx>, param_env: rustc_middle::ty::ParamEnv<'tcx>, </ins> adt_has_dtor: impl Fn(&ty::AdtDef) -> Option<DtorType>, <del> ) -> Result<&ty::List<Ty<'tcx>>, AlwaysRequiresDrop> { </del> <ins> ) -> impl Iterator<Item = NeedsDropResult<Ty<'tcx>>> { </ins> let adt_components = move |adt_def: &ty::AdtDef, substs: SubstsRef<'tcx>| { if adt_def.is_manually_drop() { <del> debug!("adt_drop_tys: `{:?}` is manually drop", adt_def); </del> <ins> debug!("drop_tys_helper: `{:?}` is manually drop", adt_def); </ins> return Ok(Vec::new().into_iter()); } else if let Some(dtor_info) = adt_has_dtor(adt_def) { match dtor_info { DtorType::Significant => { <del> debug!("adt_drop_tys: `{:?}` implements `Drop`", adt_def); </del> <ins> debug!("drop_tys_helper: `{:?}` implements `Drop`", adt_def); </ins> return Err(AlwaysRequiresDrop); } DtorType::Insignificant => { <del> debug!("adt_drop_tys: `{:?}` drop is insignificant", adt_def); </del> <ins> debug!("drop_tys_helper: `{:?}` drop is insignificant", adt_def); </ins> // Since the destructor is insignificant, we just want to make sure all of // the passed in type parameters are also insignificant.

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Encountered while running for frawk (on this specific/latest commit): Since this happened in a dependency of the project I'm building, I am not sure which line of code led to this issue. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Happens on +nightly or without +nightly : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc ICE in
Here is a relatively smaller reproduction using the  dependency: It's a bit tricky to remove im_rc, as those types have a large number of recursive generic types (via typenum).
I lost track of whether my reduction still compiled while reducing and reproducing this error, but since it's pretty small I thought I'd post it anyways. I'll see if I can reduce petgraph again, while keeping things compiling this time, so that using is more realistic, but I suspect it may also look like , and that is already pretty small.
Looks like there is also . I'll try investigate these tonight. claim
It's very similar to the previous one, and the other reductions from similar issues:
I had started looking into 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 which incorrectly assumes the values returned from still need a call. This assumption is indeed correct if that call returns the fields of the ADT (as it does if the ADT is ) but wrong if the call returns the generic params of the ADT (as it does if it is insignificant ).

That should be the cause of both this issue, , and .
Thank you for looking into this :) 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!
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
should this issue be un-pinned now that it's fixed? Or is it still pinned to track backporting?
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
The current milestone under which this issue is listed is 1.56.0, but it only got fixed in for 1.57.0. Can the milestone of this issue be updated to 1.57.0?
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.