9e394f551c
Collect relevant item bounds from trait clauses for nested rigid projections Rust currently considers trait where-clauses that bound the trait's *own* associated types to act like an item bound: ```rust trait Foo where Self::Assoc: Bar { type Assoc; } // acts as if: trait Foo { type Assoc: Bar; } ``` ### Background This behavior has existed since essentially forever (i.e. before Rust 1.0), since we originally started out by literally looking at the where clauses written on the trait when assembling `SelectionCandidate::ProjectionCandidate` for projections. However, looking at the predicates of the associated type themselves was not sound, since it was unclear which predicates were *assumed* and which predicates were *implied*, and therefore this was reworked in #72788 (which added a query for the predicates we consider for `ProjectionCandidate`s), and then finally item bounds and predicates were split in #73905. ### Problem 1: GATs don't uplift bounds correctly All the while, we've still had logic to uplift associated type bounds from a trait's where clauses. However, with the introduction of GATs, this logic was never really generalized correctly for them, since we were using simple equality to test if the self type of a trait where clause is a projection. This leads to shortcomings, such as: ```rust trait Foo where for<'a> Self::Gat<'a>: Debug, { type Gat<'a>; } fn test<T: Foo>(x: T::Gat<'static>) { //~^ ERROR `<T as Foo>::Gat<'a>` doesn't implement `Debug` println!("{:?}", x); } ``` ### Problem 2: Nested associated type bounds are not uplifted We also don't attempt to uplift bounds on nested associated types, something that we couldn't really support until #120584. This can be demonstrated best with an example: ```rust trait A where Self::Assoc: B, where <Self::Assoc as B>::Assoc2: C, { type Assoc; // <~ The compiler *should* treat this like it has an item bound `B<Assoc2: C>`. } trait B { type Assoc2; } trait C {} fn is_c<T: C>() {} fn test<T: A>() { is_c::<<Self::Assoc as B>::Assoc2>(); //~^ ERROR the trait bound `<<T as A>::Assoc as B>::Assoc2: C` is not satisfied } ``` Why does this matter? Well, generalizing this behavior bridges a gap between the associated type bounds (ATB) feature and trait where clauses. Currently, all bounds that can be stably written on associated types can also be expressed as where clauses on traits; however, with the stabilization of ATB, there are now bounds that can't be desugared in the same way. This fixes that. ## How does this PR fix things? First, when scraping item bounds from the trait's where clauses, given a trait predicate, we'll loop of the self type of the predicate as long as it's a projection. If we find a projection whose trait ref matches, we'll uplift the bound. This allows us to uplift, for example `<Self as Trait>::Assoc: Bound` (pre-existing), but also `<<Self as Trait>::Assoc as Iterator>::Item: Bound` (new). If that projection is a GAT, we will check if all of the GAT's *own* args are all unique late-bound vars. We then map the late-bound vars to early-bound vars from the GAT -- this allows us to uplift `for<'a, 'b> Self::Assoc<'a, 'b>: Trait` into an item bound, but we will leave `for<'a> Self::Assoc<'a, 'a>: Trait` and `Self::Assoc<'static, 'static>: Trait` alone. ### Okay, but does this *really* matter? I consider this to be an improvement of the status quo because it makes GATs a bit less magical, and makes rigid projections a bit more expressive. |
||
---|---|---|
.github | ||
compiler | ||
library | ||
LICENSES | ||
src | ||
tests | ||
.clang-format | ||
.editorconfig | ||
.git-blame-ignore-revs | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
.ignore | ||
.mailmap | ||
Cargo.lock | ||
Cargo.toml | ||
CODE_OF_CONDUCT.md | ||
config.example.toml | ||
configure | ||
CONTRIBUTING.md | ||
COPYRIGHT | ||
INSTALL.md | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
README.md | ||
RELEASES.md | ||
REUSE.toml | ||
rust-bors.toml | ||
rustfmt.toml | ||
triagebot.toml | ||
x | ||
x.ps1 | ||
x.py |
This is the main source code repository for Rust. It contains the compiler, standard library, and documentation.
Why Rust?
-
Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrate with other languages.
-
Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.
-
Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).
Quick Start
Read "Installation" from The Book.
Installing from Source
If you really want to install from source (though this is not recommended), see INSTALL.md.
Getting Help
See https://www.rust-lang.org/community for a list of chat platforms and forums.
Contributing
See CONTRIBUTING.md.
License
Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.
See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.
Trademark
The Rust Foundation owns and protects the Rust and Cargo trademarks and logos (the "Rust Trademarks").
If you want to use these names or brands, please read the media guide.
Third-party logos may be subject to third-party copyrights and trademarks. See Licenses for details.