Reject relaxed bounds inside associated type bounds (ATB)#135331
Merged
bors merged 1 commit intorust-lang:masterfrom Aug 11, 2025
Merged
Reject relaxed bounds inside associated type bounds (ATB)#135331bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
Conversation
fmease
added
the
rla-silenced
rustbot
added
S-waiting-on-review
Member
Author
|
@bors try |
fmease
added
S-experimental
Collaborator
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 10, 2025
[crater-only] Ban assoc ty unbounds cc rust-lang#135229 r? ghost
Collaborator
|
☀️ Try build successful - checks-actions |
Member
Author
|
@craterbot check |
Collaborator
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
Collaborator
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Collaborator
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
fmease
added
S-experimental
Contributor
|
Based on running Crater Analysis on this crater report full automated report |
fmease
added
the
needs-fcp
fmease
changed the title
TraitRef<AssocTy: …>)
fmease
changed the title
TraitRef<AssocTy: …>)TraitRef<AssocTy: …>)
fmease
changed the title
TraitRef<AssocTy: …>)
fmease
force-pushed
the
ban-assoc-ty-unbounds
branch
from
5c245de to
e7050cb
Compare
fmease
removed
T-compiler
traviscross
added
I-lang-radar
Collaborator
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
This was referenced Jul 31, 2025
Member
Author
|
Update: Crater found two new root regressions. One ( I've already sent out new "incoming breakage" PRs:
|
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Contributor
|
@bors r+ rollup |
Collaborator
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 11, 2025
Rollup of 5 pull requests Successful merges: - #135331 (Reject relaxed bounds inside associated type bounds (ATB)) - #144156 (Check coroutine upvars in dtorck constraint) - #145091 (`NllRegionVariableOrigin` remove `from_forall`) - #145194 (Ignore coroutine witness type region args in auto trait confirmation) - #145225 (Fix macro infinite recursion test to not trigger warning about semicolon in expr) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Aug 11, 2025
Rollup merge of #135331 - fmease:ban-assoc-ty-unbounds, r=lcnr Reject relaxed bounds inside associated type bounds (ATB) **Reject** relaxed bounds — most notably `?Sized` — inside associated type bounds `TraitRef<AssocTy: …>`. This was previously accepted without warning despite being incorrect: ATBs are *not* a place where we perform *sized elaboration*, meaning `TraitRef<AssocTy: …>` does *not* elaborate to `TraitRef<AssocTy: Sized + …>` if `…` doesn't contain `?Sized`. Therefore `?Sized` is meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared `$SelfTy: TraitRef, $SelfTy::AssocTy: …` we don't do sized elab either (and thus also don't allow relaxed bounds). Moreover — as I've alluded to back in #135841 (review) — some later validation steps only happen during sized elaboration during HIR ty lowering[^1]. Namely, rejecting duplicates (e.g., `?Trait + ?Trait`) and ensuring that `Trait` in `?Trait` is equal to `Sized`[^2]. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds like `Iterator<Item: ?Copy>` despite T-types's ruling established in the FCP'ed #135841). This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found ([report](#135331 (comment)), [its analysis](#135331 (comment))). [However a contributor manually found two occurrences](#135229 (comment)) of `TraitRef<AssocTy: ?Sized>` in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: Gui-Yom/turbo-metrics#14, ireina7/summon#1 (however, the owners have showed no reaction so far). I'm leaning towards banning these forms **without a FCW** because a FCW isn't worth the maintenance cost[^3]. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that. Fixes #135229. [^1]: I consider this a flaw in the implementation and [I've already added a huge FIXME](https://github.com/rust-lang/rust/blob/82a02aefe07092c737c852daccebf49ca25507e3/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs#L195-L207). [^2]: To be more precise, if the internal flag `-Zexperimental-default-bounds` is provided other "default traits" (needs internal feature `lang_items`) are permitted as well (cc closely related internal feature: `more_maybe_bounds`). [^3]: Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never *fully* remove lints).
bors
added a commit
that referenced
this pull request
Oct 20, 2025
Further tighten up relaxed bounds Follow-up to #142693, #135331 and #135841. Fixes #143122. * Reject relaxed bounds `?Trait` in the bounds of trait aliases. Just like `trait Trait {}` doesn't mean `trait Trait: Sized {}` and we therefore reject `trait Trait: ?Sized {}`, `trait Trait =;` (sic!) doesn't mean `trait Trait = Sized;` (never did!) and as a logical consequence `trait Trait = ?Sized;` is meaningless and should be forbidden. * Don't permit `?Sized` in more places (e.g., supertrait bounds, trait object types) if feature `more_maybe_bounds` is enabled. That internal feature is only meant to allow the user to define & use *new* default traits (that have fewer rules to follow for now to ease experimentation). * Unconditionally check that the `Trait` in `?Trait` is a default trait. Previously, we would only perform this check in selected places which was very brittle and led to bugs slipping through. * Slightly improve diagnostics.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 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.
Reject relaxed bounds — most notably
?Sized— inside associated type boundsTraitRef<AssocTy: …>.This was previously accepted without warning despite being incorrect: ATBs are not a place where we perform sized elaboration, meaning
TraitRef<AssocTy: …>does not elaborate toTraitRef<AssocTy: Sized + …>if…doesn't contain?Sized. Therefore?Sizedis meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared$SelfTy: TraitRef, $SelfTy::AssocTy: …we don't do sized elab either (and thus also don't allow relaxed bounds).Moreover — as I've alluded to back in #135841 (review) — some later validation steps only happen during sized elaboration during HIR ty lowering1. Namely, rejecting duplicates (e.g.,
?Trait + ?Trait) and ensuring thatTraitin?Traitis equal toSized2. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds likeIterator<Item: ?Copy>despite T-types's ruling established in the FCP'ed #135841).This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found (report, its analysis). However a contributor manually found two occurrences of
TraitRef<AssocTy: ?Sized>in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: Gui-Yom/turbo-metrics#14, ireina7/summon#1 (however, the owners have showed no reaction so far).I'm leaning towards banning these forms without a FCW because a FCW isn't worth the maintenance cost3. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that.
Fixes #135229.
Footnotes
I consider this a flaw in the implementation and I've already added a huge FIXME. ↩
To be more precise, if the internal flag
-Zexperimental-default-boundsis provided other "default traits" (needs internal featurelang_items) are permitted as well (cc closely related internal feature:more_maybe_bounds). ↩Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never fully remove lints). ↩