object-safety removed with type AssocType: PartialEq
#122798
Assignees
Labels
A-type-system
Area: Type system
C-bug
Category: This is a bug.
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
jieyouxu
added
A-type-system
Noratrieb
added a commit
to Noratrieb/rust
that referenced
this issue
Jun 4, 2024
…ference-self, r=BoxyUwU
Item bounds can reference self projections and still be object safe
### Background
Currently, we have some interesting rules about where `Self` is allowed to be mentioned in objects. Specifically, we allow mentioning `Self` behind associated types (e.g. `fn foo(&self) -> Self::Assoc`) only if that `Self` type comes from the trait we're defining or its supertraits:
```
trait Foo {
fn good() -> Self::Assoc; // GOOD :)
fn bad() -> <Self as OtherTrait>::Assoc; // BAD!
}
```
And more specifically, these `Self::Assoc` projections are *only* allowed to show up in:
* (A1) Method signatures
* (A2) Where clauses on traits, GATs and methods
But `Self::Assoc` projections are **not** allowed to show up in:
* (B1) Supertrait bounds (specifically: all *super-predicates*, which includes the projections that come from elaboration, and not just the traits themselves).
* (B2) Item bounds of associated types
The reason for (B1) is interesting: specifically, it arises from the fact that we currently eagerly elaborate all projection predicates into the object, so if we had the following code:
```
trait Sub<Assoc = Self::SuperAssoc> {}
trait Super {
type SuperAssoc;
}
```
Then given `dyn Sub<SuperAssoc = i32>` we would need to have a type that is substituted into itself an infinite number of times[^1], like `dyn Sub<SuperAssoc = i32, Assoc = <dyn Sub<SuperAssoc = i32, Assoc = <dyn Sub<SuperAssoc = i32, Assoc = <... as Super>::SuperAssoc> as Super>::SuperAssoc> as Super>::SuperAssoc>`, i.e. the fixed-point of: `type T = dyn Sub<SuperAssoc = i32, Assoc = <T as Super>::SuperAssoc>`.
Similarly for (B2), we restrict mentioning `Self::Assoc` in associated type item bounds, which is the cause for rust-lang#122798. However, there is **no reason** for us to do so, since item bounds never show up structurally in the `dyn Trait` object type.
#### What?
This PR relaxes the check for item bounds so that `Self` may be mentioned behind associated types in the same cases that they currently work for method signatures (A1) and where clauses (A2).
#### Why?
Fixes rust-lang#122798. Removes a subtle and confusing inconsistency for the code mentioned in that issue.
This is sound because we only assemble alias bounds for rigid projections, and all projections coming from an object self type are not rigid, since all associated types should be specified by the type.
This is also desirable because we can do this via supertraits already. In rust-lang#122789, it is noted that an item bound of `Eq` already works, just not `PartialEq` because of the default item bound. This is weird and should be fixed.
#### Future work
We could make the check for `Self` in super-predicates more sophisticated as well, only erroring if `Self` shows up in a projection super-predicate.
[^1]: This could be fixed by some sort of structural replacement or eager normalization, but I don't think it's necessary currently.
Noratrieb
added a commit
to Noratrieb/rust
that referenced
this issue
Jun 4, 2024
…ference-self, r=BoxyUwU
Item bounds can reference self projections and still be object safe
### Background
Currently, we have some interesting rules about where `Self` is allowed to be mentioned in objects. Specifically, we allow mentioning `Self` behind associated types (e.g. `fn foo(&self) -> Self::Assoc`) only if that `Self` type comes from the trait we're defining or its supertraits:
```
trait Foo {
fn good() -> Self::Assoc; // GOOD :)
fn bad() -> <Self as OtherTrait>::Assoc; // BAD!
}
```
And more specifically, these `Self::Assoc` projections are *only* allowed to show up in:
* (A1) Method signatures
* (A2) Where clauses on traits, GATs and methods
But `Self::Assoc` projections are **not** allowed to show up in:
* (B1) Supertrait bounds (specifically: all *super-predicates*, which includes the projections that come from elaboration, and not just the traits themselves).
* (B2) Item bounds of associated types
The reason for (B1) is interesting: specifically, it arises from the fact that we currently eagerly elaborate all projection predicates into the object, so if we had the following code:
```
trait Sub<Assoc = Self::SuperAssoc> {}
trait Super {
type SuperAssoc;
}
```
Then given `dyn Sub<SuperAssoc = i32>` we would need to have a type that is substituted into itself an infinite number of times[^1], like `dyn Sub<SuperAssoc = i32, Assoc = <dyn Sub<SuperAssoc = i32, Assoc = <dyn Sub<SuperAssoc = i32, Assoc = <... as Super>::SuperAssoc> as Super>::SuperAssoc> as Super>::SuperAssoc>`, i.e. the fixed-point of: `type T = dyn Sub<SuperAssoc = i32, Assoc = <T as Super>::SuperAssoc>`.
Similarly for (B2), we restrict mentioning `Self::Assoc` in associated type item bounds, which is the cause for rust-lang#122798. However, there is **no reason** for us to do so, since item bounds never show up structurally in the `dyn Trait` object type.
#### What?
This PR relaxes the check for item bounds so that `Self` may be mentioned behind associated types in the same cases that they currently work for method signatures (A1) and where clauses (A2).
#### Why?
Fixes rust-lang#122798. Removes a subtle and confusing inconsistency for the code mentioned in that issue.
This is sound because we only assemble alias bounds for rigid projections, and all projections coming from an object self type are not rigid, since all associated types should be specified by the type.
This is also desirable because we can do this via supertraits already. In rust-lang#122789, it is noted that an item bound of `Eq` already works, just not `PartialEq` because of the default item bound. This is weird and should be fixed.
#### Future work
We could make the check for `Self` in super-predicates more sophisticated as well, only erroring if `Self` shows up in a projection super-predicate.
[^1]: This could be fixed by some sort of structural replacement or eager normalization, but I don't think it's necessary currently.
|
Also hit this, in my case, if the associated type has a |
|
Oh, this is fixed as of 1.82 -- if you still have a problem, please file a new issue. |
Indeed, using the latest nightly toolchain, the error disappears! Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried this code:
If I uncomment out
get_foo, I get an error, butget_bardoesn't error!https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f20eef39a18a6fdc11cbeea9778ee294
To me this makes no sense since
Baris more strict thanFoo, so either: both should not compile orFooshould compile (Barmay not since it has more requirements on it's associated type).What's more fun is that this used to compile way back in v1.15.1 according to godbolt 😄 https://godbolt.org/z/TvPsjPq5o
But no version after that
Meta
playground is on v1.76.0 when I ran this
rustc --version --verbose:Compile Error
The text was updated successfully, but these errors were encountered: