-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE with type_alias_impl_trait
#99348
Comments
Thank you for reporting this issue. I have minimized this into two different issues: (1.) Checking trait and impl assoc type compatibility might constrain opaques in ways we don't observe during #![feature(type_alias_impl_trait)]
struct Concrete;
type Tait = impl Sized;
impl Foo for Concrete {
type Item = Concrete;
}
impl Bar for Concrete {
type Other = Tait;
}
trait Foo {
type Item: Bar<Other = Self>;
}
trait Bar {
type Other;
}
fn tait() -> Tait {} (2.) Borrowck's opaque type constraints differ from typeck's constraints. Probably due to reachability during mir build. #![feature(type_alias_impl_trait)]
type Tait = impl Sized;
struct One;
fn one() -> Tait { One }
struct Two<T>(T);
fn two() -> Tait { Two::<()>(todo!()) } |
You were correct about this 😜 |
Wow that example is much more minimal than mine 😀 |
No worries, the fact that you provided sample code is very well appreciated. |
…pertraits, r=oli-obk Do not constraint TAITs when checking impl/trait item compatibility Check out the UI test for the example. Open to other approaches to fix this issue -- ideally we _would_ be able to collect this opaque type constraint in a way to use it in `find_opaque_ty_constraints`, so we can report a better mismatch error in the incompatible case, and just allow it in the compatible case. But that seems like a bigger refactor, so I wouldn't want to start it unless someone else thought it was a good idea. cc rust-lang#99348 r? `@oli-obk`
…pertraits, r=oli-obk Do not constraint TAITs when checking impl/trait item compatibility Check out the UI test for the example. Open to other approaches to fix this issue -- ideally we _would_ be able to collect this opaque type constraint in a way to use it in `find_opaque_ty_constraints`, so we can report a better mismatch error in the incompatible case, and just allow it in the compatible case. But that seems like a bigger refactor, so I wouldn't want to start it unless someone else thought it was a good idea. cc rust-lang#99348 r? ``@oli-obk``
Triage: The ICE itself has been fixed by #99356 but I'm not sure why it didn't close this issue, @compiler-errors Is there a remaining task? |
There's another issue I pointed out in (2.) that remains, I'll file another task for just that and then close this out.. |
Code
Minimum reproducible example:
https://github.com/JoJoJet/bevy_param_example/blob/4ee1ab4d2ad7858df2a84a5ab2d88fc83c0d882b/src/main.rs
Meta
rustc --version --verbose
:Error output
Backtrace
The text was updated successfully, but these errors were encountered: