Change:
_: ImplSourcePointeeData, ) -> Progress<'tcx> { let tcx = selcx.tcx(); let self_ty = selcx.infcx().shallow_resolve(obligation.predicate.self_ty()); <del> let substs = tcx.mk_substs([self_ty.into()].iter()); </del> <ins> let mut obligations = vec![]; let metadata_ty = self_ty.ptr_metadata_ty(tcx, |ty| { normalize_with_depth_to( selcx, obligation.param_env, obligation.cause.clone(), obligation.recursion_depth + 1, ty, &mut obligations, ) }); let substs = tcx.mk_substs([self_ty.into()].iter()); </ins> let metadata_def_id = tcx.require_lang_item(LangItem::Metadata, None); let predicate = ty::ProjectionPredicate { projection_ty: ty::ProjectionTy { substs, item_def_id: metadata_def_id }, <del> ty: self_ty.ptr_metadata_ty(tcx), </del> <ins> ty: metadata_ty, </ins> }; confirm_param_env_candidate(selcx, obligation, ty::Binder::dummy(predicate), false) <ins> .with_addl_obligations(obligations) </ins> } fn confirm_fn_pointer_candidate<'cx, 'tcx>(

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. -- <!-- 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. --(Build fails with an ICE on current stable/beta/nightly on the playground.) <!-- : --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Same error message as , though it's unclear whether that issue is related.
Minimized: The trait gets used by the impl for , which leads to the bad monomorphization: The issue is caused by how we handle projections when computing the type. We don't normalize the 'tail' type: which causes us to not create a candidate for the projection type in the tail of (which is ): cc - we need to be normalizing somewhere*, but I'm not exactly sure where the correct place is.
I’m sorry but I don’t think I can help much. I don’t even know what normalizing means precisely. As I mentioned in So the only hint I can offer is: does the code for do something differently? Or is there a reason it’s not affected by this problem?
cc - I'm not quite sure what the proper normalization behavior is. We need to be able to perform this projection during typecheck (e.g. ), so I think we need to try to faillibly normalize the trailing field type here?
Why are we not normalizing? Because we don't want to replace with an inference var?
so I put up a fix for this in . Someone mind reviewing that PR? It's gone some time without being touched. My PR seems to successfully compile both examples linked in this issue. Is it really not sufficient to just normalize during selection? Are there any consequences of normalization failing here, other than giving us errors the regular ambiguity "type annotation needed" errors?

<!-- 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. -- causes rustc to ICE: <!-- 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. --: <!-- 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 --<!-- TRIAGEBOTEND --
I've got a fix for this. I'll put it up in the morning. claim

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The code compiles successfully Instead, this happened: There are two errors, despite the error sites apparently being no different from the successfully compiled ones, aside from the presence of generic type inference. I couldn't get this to happen with a user-defined trait, so it may be related to 's magic implementations. On the other hand, it may be possible to trigger via user code and I just couldn't find an example. <!-- 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. --Playground Nightly Version Used: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I've confirmed this is fixed by the same fix I'll be putting up for . claim