Only include dyn Trait<Assoc = ...> associated type bounds for Self: Sized associated types if they are provided#140684
Merged
bors merged 2 commits intorust-lang:masterfrom May 9, 2025
Conversation
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.
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