Confirming built-in higher-ranked Future (and other coroutine) goals ICEs #121653
Labels
C-bug
Category: This is a bug.
F-unboxed_closures
`#![feature(unboxed_closures)]`
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
compiler-errors
added
I-ICE
rustbot
added
the
needs-triage
|
duplicate of #112347 maybe? |
|
We can hit this for all kinds of built-in coroutine/closure-based goals 💀 //@ edition:2024
//@ compile-flags: -Zunstable-options
//@ build-fail
#![feature(unboxed_closures, gen_blocks)]
use std::future::Future;
trait Dispatch {
fn dispatch(self);
}
struct Fut<T>(T);
impl<T: for<'a> Fn<(&'a (),)>> Dispatch for Fut<T>
where
for<'a> <T as FnOnce<(&'a (),)>>::Output: Future,
{
fn dispatch(self) {
(self.0)(&());
}
}
struct Gen<T>(T);
impl<T: for<'a> Fn<(&'a (),)>> Dispatch for Gen<T>
where
for<'a> <T as FnOnce<(&'a (),)>>::Output: Iterator,
{
fn dispatch(self) {
(self.0)(&());
}
}
struct Closure<T>(T);
impl<T: for<'a> Fn<(&'a (),)>> Dispatch for Closure<T>
where
for<'a> <T as FnOnce<(&'a (),)>>::Output: Fn<(&'a (),)>,
{
fn dispatch(self) {
(self.0)(&())(&());
}
}
fn main() {
async fn foo(_: &()) {}
Fut(foo).dispatch();
gen fn bar(_: &()) {}
Gen(bar).dispatch();
fn uwu<'a>(x: &'a ()) -> impl Fn(&'a ()) { |_| {} }
Closure(uwu).dispatch();
} |
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Feb 29, 2024
…f, r=oli-obk Fix `async Fn` confirmation for `FnDef`/`FnPtr`/`Closure` types Fixes three issues: 1. The code in `extract_tupled_inputs_and_output_from_async_callable` was accidentally getting the *future* type and the *output* type (returned by the future) messed up for fnptr/fndef/closure types. :/ 2. We have a (class of) bug(s) in the old solver where we don't really support higher ranked built-in `Future` goals for generators. This is not possible to hit on stable code, but [can be hit with `unboxed_closures`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e935de7181e37e13515ad01720bcb899) (rust-lang#121653). * I'm opting not to fix that in this PR. Instead, I just instantiate placeholders when confirming `async Fn` goals. 4. Fixed a bug when generating `FnPtr` shims for `async Fn` trait goals. r? oli-obk
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 29, 2024
Rollup merge of rust-lang#121654 - compiler-errors:async-fn-for-fn-def, r=oli-obk Fix `async Fn` confirmation for `FnDef`/`FnPtr`/`Closure` types Fixes three issues: 1. The code in `extract_tupled_inputs_and_output_from_async_callable` was accidentally getting the *future* type and the *output* type (returned by the future) messed up for fnptr/fndef/closure types. :/ 2. We have a (class of) bug(s) in the old solver where we don't really support higher ranked built-in `Future` goals for generators. This is not possible to hit on stable code, but [can be hit with `unboxed_closures`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e935de7181e37e13515ad01720bcb899) (rust-lang#121653). * I'm opting not to fix that in this PR. Instead, I just instantiate placeholders when confirming `async Fn` goals. 4. Fixed a bug when generating `FnPtr` shims for `async Fn` trait goals. r? oli-obk
fmease
added
F-unboxed_closures
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 18, 2024
…r=<try> Eagerly instantiate closure/coroutine-like bounds with placeholders to deal with binders correctly A follow-up to rust-lang#119849, however it aims to fix a different set of issues. Currently, we have trouble confirming goals where built-in closure/fnptr/coroutine signatures are compared against higher-ranked goals. Currently, we don't support goals like `for<'a> fn(&'a ()): Fn(&'a ())` because we don't expect the self type of goal to reference any bound regions from the goal, because we don't really know how to deal with the double binder of predicate + self type. However, this definitely can be reached (rust-lang#121653) -- and in fact, it results in post-mono errors in the case of rust-lang#112347 where the builtin type (e.g. a coroutine) is hidden behind a TAIT. The proper fix here is to instantiate the goal before trying to extract the signature from the self type. See final two commits. r? lcnr
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 2, 2024
…r=lcnr Eagerly instantiate closure/coroutine-like bounds with placeholders to deal with binders correctly A follow-up to rust-lang#119849, however it aims to fix a different set of issues. Currently, we have trouble confirming goals where built-in closure/fnptr/coroutine signatures are compared against higher-ranked goals. Currently, we don't support goals like `for<'a> fn(&'a ()): Fn(&'a ())` because we don't expect the self type of goal to reference any bound regions from the goal, because we don't really know how to deal with the double binder of predicate + self type. However, this definitely can be reached (rust-lang#121653) -- and in fact, it results in post-mono errors in the case of rust-lang#112347 where the builtin type (e.g. a coroutine) is hidden behind a TAIT. The proper fix here is to instantiate the goal before trying to extract the signature from the self type. See final two commits. r? lcnr
|
this was fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to #108834, but for coroutine-based built-in goals.
Code
Backtrace
The text was updated successfully, but these errors were encountered: