Correctly resolve Inherent Associated Types #103621
Merged
Conversation
This file contains 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
fee1-dead
added
the
F-inherent_associated_types
|
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
fee1-dead
force-pushed
the
iat-fix-use
branch
from
8e090c6 to
5fbc290
Compare
This comment has been minimized.
This comment has been minimized.
fee1-dead
force-pushed
the
iat-fix-use
branch
2 times, most recently
from
5d59438 to
809b831
Compare
cjgillot
reviewed
Oct 31, 2022
|
I don't think I have enough context to do give a good review here. r? @cjgillot Feel free to reroll if you didn't want to take over the review 🙂 |
fee1-dead
force-pushed
the
iat-fix-use
branch
from
809b831 to
3aef6c6
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
|
I am not sure this is what we want, it seems like closer to what we want is for assoc types to stay unresolved into typeck so that for example: |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 5, 2022
Rollup of 6 pull requests Successful merges: - rust-lang#103621 (Correctly resolve Inherent Associated Types) - rust-lang#103660 (improve `filesearch::get_or_default_sysroot`) - rust-lang#103866 (Remove some return-type diagnostic booleans from `FnCtxt`) - rust-lang#103867 (Remove `has_errors` from `FnCtxt`) - rust-lang#103994 (Specify that `break` cannot be used outside of loop *or* labeled block) - rust-lang#103995 (Small round of typo fixes) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Out of curiosity, can it ever work? Are there cases where it's possible to infer |
|
projections arent injective but we still relate the substs, so |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 16, 2022
Respect visibility & stability of inherent associated types As discussed in rust-lang#103621, this probably won't be the final location of the code that resolves inherent associated types. Still, I think it's valuable to push correctness fixes for this feature (in regards to visibility and stability). Let me know if I should write a translatable diagnostic instead and if I should move the tests to `privacy/` and `stability-attribute/` respectively. Fixes rust-lang#104243. `@rustbot` label A-visibility F-inherent_associated_types r? `@cjgillot` (since you reviewed rust-lang#103621, feel free to reroll though)
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Nov 16, 2022
Respect visibility & stability of inherent associated types As discussed in rust-lang#103621, this probably won't be the final location of the code that resolves inherent associated types. Still, I think it's valuable to push correctness fixes for this feature (in regards to visibility and stability). Let me know if I should write a translatable diagnostic instead and if I should move the tests to `privacy/` and `stability-attribute/` respectively. Fixes rust-lang#104243. ``@rustbot`` label A-visibility F-inherent_associated_types r? ``@cjgillot`` (since you reviewed rust-lang#103621, feel free to reroll though)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 16, 2022
Respect visibility & stability of inherent associated types As discussed in rust-lang#103621, this probably won't be the final location of the code that resolves inherent associated types. Still, I think it's valuable to push correctness fixes for this feature (in regards to visibility and stability). Let me know if I should write a translatable diagnostic instead and if I should move the tests to `privacy/` and `stability-attribute/` respectively. Fixes rust-lang#104243. ```@rustbot``` label A-visibility F-inherent_associated_types r? ```@cjgillot``` (since you reviewed rust-lang#103621, feel free to reroll though)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 16, 2022
Respect visibility & stability of inherent associated types As discussed in rust-lang#103621, this probably won't be the final location of the code that resolves inherent associated types. Still, I think it's valuable to push correctness fixes for this feature (in regards to visibility and stability). Let me know if I should write a translatable diagnostic instead and if I should move the tests to `privacy/` and `stability-attribute/` respectively. Fixes rust-lang#104243. ````@rustbot```` label A-visibility F-inherent_associated_types r? ````@cjgillot```` (since you reviewed rust-lang#103621, feel free to reroll though)
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this pull request
Jan 6, 2023
Rollup of 6 pull requests Successful merges: - rust-lang#103621 (Correctly resolve Inherent Associated Types) - rust-lang#103660 (improve `filesearch::get_or_default_sysroot`) - rust-lang#103866 (Remove some return-type diagnostic booleans from `FnCtxt`) - rust-lang#103867 (Remove `has_errors` from `FnCtxt`) - rust-lang#103994 (Specify that `break` cannot be used outside of loop *or* labeled block) - rust-lang#103995 (Small round of typo fixes) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 20, 2023
…jackh726 Type-directed probing for inherent associated types When probing for inherent associated types (IATs), equate the Self-type found in the projection with the Self-type of the relevant inherent impl blocks and check if all predicates are satisfied. Previously, we didn't look at the Self-type or at the bounds and just picked the first inherent impl block containing an associated type with the name we were searching for which is obviously incorrect. Regarding the implementation, I basically copied what we do during method probing (`assemble_inherent_impl_probe`, `consider_probe`). Unfortunately, I had to duplicate a lot of the diagnostic code found in `rustc_hir_typeck::method::suggest` which we don't have access to in `rustc_hir_analysis`. Not sure if there is a simple way to unify the error handling. Note that in the future, `rustc_hir_analysis::astconv` might not actually be the place where we resolve inherent associated types (see rust-lang#103621 (comment)) but `rustc_hir_typeck` (?) in which case the duplication may naturally just disappear. While inherent associated *constants* are currently resolved during "method" probing, I did not find a straightforward way to incorporate IAT lookup into it as types and values (functions & constants) are two separate entities for which distinct code paths are taken. Fixes rust-lang#104251 (incl. rust-lang#104251 (comment)). Fixes rust-lang#105305. Fixes rust-lang#107468. `@rustbot` label T-types F-inherent_associated_types r? types
RalfJung
pushed a commit
to RalfJung/miri
that referenced
this pull request
Feb 20, 2023
Type-directed probing for inherent associated types When probing for inherent associated types (IATs), equate the Self-type found in the projection with the Self-type of the relevant inherent impl blocks and check if all predicates are satisfied. Previously, we didn't look at the Self-type or at the bounds and just picked the first inherent impl block containing an associated type with the name we were searching for which is obviously incorrect. Regarding the implementation, I basically copied what we do during method probing (`assemble_inherent_impl_probe`, `consider_probe`). Unfortunately, I had to duplicate a lot of the diagnostic code found in `rustc_hir_typeck::method::suggest` which we don't have access to in `rustc_hir_analysis`. Not sure if there is a simple way to unify the error handling. Note that in the future, `rustc_hir_analysis::astconv` might not actually be the place where we resolve inherent associated types (see rust-lang/rust#103621 (comment)) but `rustc_hir_typeck` (?) in which case the duplication may naturally just disappear. While inherent associated *constants* are currently resolved during "method" probing, I did not find a straightforward way to incorporate IAT lookup into it as types and values (functions & constants) are two separate entities for which distinct code paths are taken. Fixes #104251 (incl. rust-lang/rust#104251 (comment)). Fixes #105305. Fixes #107468. `@rustbot` label T-types F-inherent_associated_types r? types
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I don't know if this is the best way to do this, but at least it is one way.