Change:
Some(ty::Instance::new(leaf_def.item.def_id, substs)) } <del> traits::ImplSource::Generator(generator_data) => Some(Instance { def: ty::InstanceDef::Item(generator_data.generator_def_id), substs: generator_data.substs, }), traits::ImplSource::Future(future_data) => Some(Instance { def: ty::InstanceDef::Item(future_data.generator_def_id), substs: future_data.substs, }), </del> <ins> traits::ImplSource::Generator(generator_data) => { if cfg!(debug_assertions) && tcx.item_name(trait_item_id) != sym::resume { // For compiler developers who'd like to add new items to `Generator`, // you either need to generate a shim body, or perhaps return // `InstanceDef::Item` pointing to a trait default method body if // it is given a default implementation by the trait. span_bug!( tcx.def_span(generator_data.generator_def_id), "no definition for `{trait_ref}::{}` for built-in generator type", tcx.item_name(trait_item_id) ) } Some(Instance { def: ty::InstanceDef::Item(generator_data.generator_def_id), substs: generator_data.substs, }) } traits::ImplSource::Future(future_data) => { if cfg!(debug_assertions) && tcx.item_name(trait_item_id) != sym::poll { // For compiler developers who'd like to add new items to `Future`, // you either need to generate a shim body, or perhaps return // `InstanceDef::Item` pointing to a trait default method body if // it is given a default implementation by the trait. span_bug!( tcx.def_span(future_data.generator_def_id), "no definition for `{trait_ref}::{}` for built-in async generator type", tcx.item_name(trait_item_id) ) } Some(Instance { def: ty::InstanceDef::Item(future_data.generator_def_id), substs: future_data.substs, }) } </ins> traits::ImplSource::Closure(closure_data) => { <ins> if cfg!(debug_assertions) && ![sym::call, sym::call_mut, sym::call_once] .contains(&tcx.item_name(trait_item_id)) { // For compiler developers who'd like to add new items to `Fn`/`FnMut`/`FnOnce`, // you either need to generate a shim body, or perhaps return // `InstanceDef::Item` pointing to a trait default method body if // it is given a default implementation by the trait. span_bug!( tcx.def_span(closure_data.closure_def_id), "no definition for `{trait_ref}::{}` for built-in closure type", tcx.item_name(trait_item_id) ) } </ins> let trait_closure_kind = tcx.fn_trait_kind_from_def_id(trait_id).unwrap(); Instance::resolve_closure( tcx,

Discussion:
In , I a combinator that always returns . However, the corresponding test in crashes with a segfault, instead of hanging indefinitely (the expected behavior for this incomplete implementation). According to GDB, the test function is miscompiled quite badly, and just unconditionally dereferences a NULL pointer when run: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Is this like... the futures version of
I'll minimize this a bit claim
Uhh this is as much as I could minimize it -- not sure if it's segfaulting because I minimized it poorly or because it actually repro's this issue, but it's a start!! :laughing: <details</details
Thanks I was able to use your test case to look into it a bit further. The issue looks related to the Future trait, I wasn't able to reproduce it using other traits. In the example below I changed the trait definition to this: And the call to fails to compile with this LLVM error: Compile in debug mode to see the error, release mode doesn't complain and outputs code that segfaults. <details</details
In , the call to is incorrectly resolved to , i.e., .
Thanks I can look into why we're resolving this method to the wrong instance...
Ah. This isn't a user-facing bug, but a bug in that expects the trait to have one method. :facepalm: So it turns out that this really isn't that high-prio of a bug. It still needs fixing, and that method could use some major robustness checks, at least when debug assertions are enabled. I'll take a stab at it. claim
I'm going to remove the unsoundness tag and I think this probably doesn't need to be prioritized (or at least doesn't need to be anything higher than like... P-high) because this really has to do with an incongruency between and the compiler's assumption about the contents of the trait. That being said, this bug still sucks and I'm sorry that had to deal with it, but nothing like this is possible to trigger without and a trait definition for that diverges from the one in libstd currently. (that being said, I will still fix this bug and make it harder to trigger in the future)