Change:
<ins> error[E0277]: the trait bound `T: SomeTrait<'_>` is not satisfied --> $DIR/issue-85455.rs:8:5 | LL |     callee::<fn(&()) -> <T as SomeTrait<'_>>::Associated>(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `SomeTrait<'_>` is not implemented for `T` | help: consider restricting type parameter `T` | LL | fn give_me_ice<T: SomeTrait<'_>>() { |                 +++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
on the following code produces an ICE (just doesn’t ICE) () Possibly, this bug can also lead to unsoundness in some way. (I haven’t fully explored that [yet].) Notably, doesn’t come with the same problem: I would’ve expected a similar error message for the case as well. (Further, note that the way things currently stand, the type itself is . It’s only the call to which has an bound. The error also successfully appears if has a higher-ranked bound and/or is not actually called but just instantiated with the type argument, .) label requires-nightly, F-unboxedclosures, A-traits, A-typesystem, A-associated-items
Fixed by , different enough that marking as needs-test

<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --Strangely the backtrace is empty (I got the error output section with ). Should I report that bug separately?
This also crashes on nightly, but it has a backtrace there (not that it's very helpful): can you see if using nightly gets you a backtrace?
I can't get a normal backtrace even on nightly, however I can get one with (on both stable and nightly), but I don't think it will be very helpful:
For s you can get the backtrace for where they were originally issued with : (Should we automatically capture backtraces of when is set?)
I can see how this would be fixed by , but we don't have a test like this. Marking as needs-test.

<!-- 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. --EDIT: MCVE is . <!-- 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. --Also reproducible on beta and 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 --<!-- TRIAGEBOTEND --
Slightly smaller: There are a few strange things about this: you remove from , or if you remove , it gives a different ICE: <details<summaryBacktrace</summary</detailsyou make any of the functions unreachable, it compiles fine. Presumably the compiler notices they're unused and don't need to be monomorphized. you change the trait definition of to remove the associated items and return instead, it compiles fine. you remove and manually inline it into , it compiles fine.
Relevant code:
Removing still gives ICE, that's weird as I left it intentionally because previously it was required to reproduce; anyway it can be removed now to simplify the example Edit: Should it be labeled with some priority as it is an ICE on Stable?
can you remove 'dep and post the new code? I don't have time right now. Normally issues aren't prioritized unless they're regressions or unsound, but I can make an exception since you asked nicely :)
it's up to you, but many thanks anyway!

I just tried to remove 'dep for a simplified example you posted and it compiles, but it doesn't compile for a snippet I posted first, so here is a version that sill larger than yours, but without lifetime parameter for a User struct:
Turns out this is a regression: the code works on 1.47 and ICEs on 1.48. searched nightlies: from nightly-2020-08-24 to nightly-2020-11-14 regressed nightly: nightly-2020-11-09 searched commits: from to regressed commit: (, backported to 1.48 in ) <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable also, since no-one's posted a reduction without the use of async/await: label A-async-await
rustbot did not like that, huh label A-async-await
Here's a no-dependency version that gives the alternate ICE from says it regressed in the same commit, so probably the same root cause:
To my understanding, this is expected. A function needs to be used in order to be monomorphized; otherwise what whould it be monomorphized to? So, if the bug happens during monomorphization, it should only happen for functions that are actually used (and thus instantiated).
Assigning as discussed as part of the .3A.20thread.20'rustc'.20panicked.20at.20'called.20.60Opt.E2.80.A6) and removing .
In the minimized version above (), codegenning debuginfo fails because it doesn't know the layout of the unnormalized type , which appears in the MIR locals for the method. I think this type should have been normalized during monomorphization. do you know why might have caused this type to remain unnormalized?
is a query, right? Could the backend call it on-demand instead of crashing?
It could, but it should already have been done (unless I'm confused). So either is not working for that type, or some earlier code is not normalizing where it should – either way we should understand more about what's going on.
Fixed by , but not sure how.

Going to mark as needs-test, since this case is different from others.
This ICE has since . a test but marked it as check-pass. This did not reproduce the failure which only occurs when codegen runs. <details<summaryBacktrace</summary</details
all examples seem to run now, marking as again
claim
visiting for P-high review. from what I can tell from the dialogue here, is the test we want, and is now correctly marked as build-pass thanks to PR closing as fixed