ICE with missing bound in TAIT with closures/async #90409
Assignees
Labels
C-bug
Category: This is a bug.
F-type_alias_impl_trait
`#[feature(type_alias_impl_trait)]`
glacier
ICE tracked in rust-lang/glacier.
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
SNCPlay42
added
C-bug
|
This version, using a custom trait instead of #![feature(type_alias_impl_trait)]
trait Bar {
fn bar(&self);
}
trait Baz {
fn baz(&self);
}
struct MyBaz<B: Bar>(B);
impl <B: Bar> Baz for MyBaz<B> {
fn baz(&self) {}
}
type FooFn<B> = impl Baz;
fn foo<B: Bar>(bar: B) -> FooFn<B> {
MyBaz(bar)
}
fn main() {
let boom: FooFn<u32> = unsafe { core::mem::zeroed() };
boom.baz();
}The compiler should reject the other two versions for the same reason. |
|
Interestingly #![feature(type_alias_impl_trait)]
trait Bar {
fn bar(&self);
}
type FooFn<B> = impl FnOnce(B);
fn foo<B: Bar>() -> FooFn<B> {
fn mop<B: Bar>(bar: B) { bar.bar() }
mop as fn(B) // NOTE: function pointer
}
fn main() {
let boom: FooFn<u32> = unsafe { core::mem::zeroed() };
boom(42);
}compiles and blows up at runtime while errors |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 10, 2022
…dtwco Check hidden types for well formedness at the definition site instead of only at the opaque type itself work towards rust-lang#90409 . We'll need to look into closure and generator bodies of closures and generators nested inside the hidden type in order to fix that. In hindsight this PR is not necessary for that, but it may be a bit easier with it and we'll get better diagnostics from it on its own.
|
Note that #90409 (comment) still triggers an ICE, @oli-obk could you check? |
|
The example in your linked comment didn't ICE before and doesn't now. It links to a different issue which ICEs, did you mean that? |
|
Oh sorry, I meant "code 2" on OP: #![feature(type_alias_impl_trait)]
use std::future::Future;
trait Bar {
fn bar(&self);
}
type FooFuture<B> = impl Future<Output = ()>;
fn foo<B: Bar>(bar: B) -> FooFuture<B> {
async move { bar.bar() }
}
pub fn mainish(ctx: &mut std::task::Context) {
let boom: FooFuture<u32> = unsafe { core::mem::zeroed() };
Box::pin(boom).as_mut().poll(ctx);
} |
|
Oh interesting, this happens only with |
Merged
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this issue
Jul 19, 2022
wf-check generators fixes rust-lang#90409 We should not rely on generators being well formed by construction now that they can get used via type alias impl trait (and thus users can choose generic arguments that are invalid). This can cause surprising behaviour if (definitely unsound) transmutes are used, and it's generally saner to just check for well formedness.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code
(Derived from #90400, but with a non-associated type alias instead of a GAT)
playground
Meta
rustc --version --verbose:Error output
Backtrace
Code 2
Using async instead of a closure produces a very similar ICE.
playground
Backtrace
@rustbot label F-type_alias_impl_trait
The text was updated successfully, but these errors were encountered: