Only include dyn Trait<Assoc = ...> associated type bounds for Self: Sized associated types if they are provided
#140684
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
rustbot
added
S-waiting-on-review
|
HIR ty lowering was modified cc @fmease |
lcnr
reviewed
May 6, 2025
…f they are provided
compiler-errors
force-pushed
the
unnecessary-assoc
branch
from
f595989 to
4f72796
Compare
lcnr
reviewed
May 7, 2025
| } | ||
|
|
||
| impl Other for dyn Trait {} | ||
| // `dyn Trait<Assoc = ()>` is a different "nominal type" than `dyn Traiat`. |
There was a problem hiding this comment.
Suggested change
| // `dyn Trait<Assoc = ()>` is a different "nominal type" than `dyn Traiat`. | |
| // `dyn Trait<Assoc = ()>` is a different "nominal type" than `dyn Trait`. |
lcnr
added
the
beta-nominated
|
cc @rust-lang/types this PR fixes an unintended side-effect of a larger change from #136458. r=me after nit |
compiler-errors
force-pushed
the
unnecessary-assoc
branch
from
4f72796 to
3799d84
Compare
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
May 8, 2025
… r=lcnr Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided Since rust-lang#136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given: ```rust trait Trait { type Assoc where Self: Sized; } ``` After rust-lang#136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing. After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list. This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before rust-lang#136458. We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in rust-lang#136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future. Fixes rust-lang#140645 r? lcnr
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 8, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#140095 (Eliminate `word_and_empty` methods.) - rust-lang#140341 (Clarify black_box warning a bit) - rust-lang#140684 (Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided) - rust-lang#140707 (Structurally normalize in range pattern checking in HIR typeck) - rust-lang#140716 (Improve `-Zremap-path-scope` tests with dependency) - rust-lang#140800 (Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux) - rust-lang#140802 (Add release notes for 1.87.0) - rust-lang#140811 (Enable triagebot note functionality for rust-lang/rust) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
Rollup merge of rust-lang#140684 - compiler-errors:unnecessary-assoc, r=lcnr Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided Since rust-lang#136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given: ```rust trait Trait { type Assoc where Self: Sized; } ``` After rust-lang#136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing. After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list. This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before rust-lang#136458. We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in rust-lang#136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future. Fixes rust-lang#140645 r? lcnr
pietroalbini
added
beta-accepted
|
Accepting for beta backport (directly into the stable PR) given the vote in Zulip. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
[stable] Prepare the 1.87.0 release Preparing the stable artifacts as described in the release process. This PR also includes the following last minute backports: * rust-lang#140810 * rust-lang#140601 * rust-lang#140684 r? `@ghost`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
[stable] Prepare the 1.87.0 release Preparing the stable artifacts as described in the release process. This PR also includes the following last minute backports: * rust-lang#140810 * rust-lang#140601 * rust-lang#140684 r? `@ghost`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Since #136458, we began filtering out associated types with
Self: Sizedbounds when constructing the list of associated type bounds to put into ourdyn Traittypes. For example, given:After #136458, even if a user writes
dyn Trait<Assoc = ()>, the lowered ty would have an empty projection list, and thus be equivalent todyn Trait. However, this has the side effect of no longer constraining any types in the RHS ofAssoc = ..., not implying any WF implied bounds, and not requiring that they hold when unsizing.After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list.
This results in
dyn Traittypes that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. betweendyn Traitanddyn Trait<Assoc = ()>. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before #136458.We may want to begin to ignore thse bounds in the future by bumping
unused_associated_type_boundsto an FCW. I don't want to tangle that up into the fix that was originally intended in #136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future.Fixes #140645
r? lcnr