-
Notifications
You must be signed in to change notification settings - Fork 13.4k
ICE with type_alias_impl_trait
#99348
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.. |
Uh oh!
There was an error while loading. Please reload this page.
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: