-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Spurious "bounds [...] not enforced in type aliases" when using TAIT #108617
Comments
Currently, this lint passes |
@rustbot claim |
In #108663 we figured out that we could add |
Add `AliasKind::Weak` for type aliases. `type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a ```rust trait Identity { type Identity; } impl<T: Debug> Identity for T { type Identity = T; } <NotDebug as Identity>::Identity ``` type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer. Similarly: * a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes * rustdoc expands the type alias, even though often times users use them for documentation purposes * diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about. For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident. To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition. Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds. As a side effect, easily allows fixing rust-lang/rust#108617, which I did. fixes rust-lang/rust#108617
Code
Current output
Desired output
No warning at all, I think, since the bound is actually checked; applying the suggestion yields code that does not compile.
Rationale and extra context
No response
Other cases
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: