Rust: Paths to associated types resolve to the associated type if implementation is unclear #21188
+1,897
−1,420
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
paldepind
force-pushed
the
rust/self-path-assoc
branch
5 times, most recently
from
eca7559 to
8a465bd
Compare
paldepind
force-pushed
the
rust/self-path-assoc
branch
from
8a465bd to
7e74844
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
||
| override Namespace getNamespace() { | ||
| result.isType() // can be referenced with `Self` | ||
| // `impl` blocks are refered to using `Self` paths which can appear both as |
Check warning
Code scanning / CodeQL
Misspelling Warning
Comment on lines
+12
to
+27
| /** | ||
| * Constructing the "type hierachy" (that is, the trait hierachy and how types | ||
| * implements trait) in the shared type inference library relies on type | ||
| * mentions. | ||
| * | ||
| * Furthermore, resolving type mentions such as `<Type as Trait>::AssocType` | ||
| * relies on knowing how `Type` implements `Trait`. This makes type mentions and | ||
| * the type hierachy recursively dependentent, which causes non-monotonic | ||
| * recursion. | ||
| * | ||
| * To avoid the recursion, we parameterize the `TypeMention` by a predicate for | ||
| * resolving "additional" types for paths. A first instantion uses the empty | ||
| * predicate to create `PreTypeMention` which is used to construct the type | ||
| * hierachy. Afterwards, a second instantion uses a predicate that can resolve | ||
| * paths that rely on the type hierachy to create the actual `TypeMention`. | ||
| */ |
Check warning
Code scanning / CodeQL
Misspelling Warning
| typePath = TypePath::singleton(TSelfTypeParameter(this)) and | ||
| result = TSelfTypeParameter(this) | ||
| or | ||
| exists(TypeAlias alias | |
Check warning
Code scanning / CodeQL
Omittable 'exists' variable Warning
…on concrete types
paldepind
force-pushed
the
rust/self-path-assoc
branch
from
7e74844 to
2f88971
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to handle paths that access an associated type on a concrete type (concrete meaning not a type parameter) in
TypeMention.In practise these paths fall into one of two cases:
<Foo as Trait>::AssocwhereFoocan be an arbitrarily complex type.Self::Associnside animplblock. For animplblock of the formimpl Trait for Foosuch a path is basically sugar for the above.A key point is that resolving the associated type relies on how the concrete type implements the trait that the associated type is from. For instance, the added tests have examples where
<Odd<i32> as GetSet>::Outputis equal toboolbut<Odd<bool> as GetSet>::Outputis equal tochar.Today case 1 above is unhandled and case 2 is somewhat handled inside path resolution. But path resolution doesn't understand how types implement trais: For a
Self::Assocpath we find all associated types with the nameAssocacross all traits thatSelfimplement. This leads to spurious path resolutions as seen in the tests.To address the above, this PR tweaks path resolution such that a
Self::Assocpath resolves to the associated type in the trait whereAssocis from (except whenAssocis defined directly in theimplblock thatSelfbelongs to). This is does not depend on type information, so it can be done correctly in path resolution.After that we use the
SatisfiesConstraintmodule inTypeMentionto find the correct trait implementations and read the associated types off of those. When implementing this I ran into non-monotonic recursion. The problem as well as the workaround is documented in the comment for theMkTypeMentionmodule.