Change:
<ins> // build-pass // edition:2021 // compile-flags: -Cdebuginfo=2 // We were not normalizing opaques with escaping bound vars during codegen, // leading to later linker errors because of differences in mangled symbol name. fn func<T>() -> impl Sized {} trait Trait<'a> { type Assoc; fn call() { let _ = async { let _value = func::<Self::Assoc>(); std::future::ready(()).await }; } } impl Trait<'static> for () { type Assoc = (); } fn main() { <()>::call(); } </ins>

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. --: The error does not happen with any of the 3 changes bellow Remove the async keyword Remove the parameter from the trait function Add the type constraint to struct
label +A-llvm +A-debuginfo +F-asyncfnin_trait Requires and to reproduce As far as I can tell this has caused an ICE since it was introduced in With debug assertions, this fails a bit earlier:
This should be fixed by , if that ever lands.

I tried this code: I expected to see this happen: The code would compile and link normally, and run Instead, this happened: Compilation failed with the following linker error: This failure seems to only occurs if the is defined in the trait, and the trait must have a lifetime parameter. The above is a minimum reproducing case that managed to produce on the forums, based of a more convoluted reproducing case I originally had (). They also produced a version that uses a generator to cause a similar linker failure (in nightly), with very similar setup () and pointed to as a possible suspect (based on bisecting the issue). Let me know if any more information is needed, thanks! : Also failed with nightly:
label T-compiler -regression-untriaged +regression-from-stable-to-stable For clarification (for prioritization): This regression happens between and , so it’s not a very recent regression. Of course, hitting such a linking error is a serious bug either way.

Bisection looks like searched toolchains nightly-2021-09-27 through nightly-2021-09-30 Regression in nightly-2021-09-28 fetching nightly manifest 2021-09-27: 40 B / 40 B [=========================================================================================================================] 100.00 % 344.14 KB/s converted 2021-09-27 to fetching nightly manifest 2021-09-28: 40 B / 40 B [=========================================================================================================================] 100.00 % 396.34 KB/s converted 2021-09-28 to looking for regression commit between 2021-09-27 and 2021-09-28 fetching (via remote github) commits from max(, 2021-09-25) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 8 commit[0] 2021-09-26UTC: Auto merge of - sexxi-goose:insigstdlib, r=nikomatsakis commit[1] 2021-09-26UTC: Auto merge of - bjorn3:synccgclif-2021-09-19, r=bjorn3 commit[2] 2021-09-27UTC: Auto merge of - rusticstuff:bumpstdarch, r=kennytm commit[3] 2021-09-27UTC: Auto merge of - GuillaumeGomez:boostrap-explicit-request, r=Mark-Simulacrum commit[4] 2021-09-27UTC: Auto merge of - GuillaumeGomez:cleanup-rustdoc-types, r=camelid commit[5] 2021-09-27UTC: Auto merge of - TaKO8Ki:suggest-both-immutable-and-mutable-trait-implementations, r=estebank commit[6] 2021-09-27UTC: Auto merge of - jackh726:issue-, r=nikomatsakis commit[7] 2021-09-27UTC: Auto merge of - smoelius:register_tool, r=petrochenkov ERROR: no CI builds available between and within last 167 day
Hm, I bet it's
Given that was a revert of , and that it was un-reverted by , I wonder if simply unmasked a regression that occurred between and .

WG-prioritization assigning priority (). label -I-prioritize +P-high
I don't think this is the case. This is definitely caused by , which was fixed by , and then un-fixed by . I'm gonna try to look into fixing this behavior for real in .
seems the symbol names get normalized correctly with
Hey folks, really appreciate you all looking at this. Is there any update? Anything I can do to assist? I'll admit the technical details of the failure here are beyond me though :laughing:
Out of curiosity, how does this look like today on nightly, now that is gone completely? This might also be related / a duplicate of , as that describes a similar linker error.
This linker error happens with any generic function that takes the generator type. See, e.g., my :