Reject relaxed bounds inside associated type bounds (ATB)

[fmease]

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¹. Namely, rejecting duplicates (e.g., ?Trait + ?Trait) and ensuring that Trait in ?Trait is equal to Sized². 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, 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 cost³. 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

1. I consider this a flaw in the implementation and I've already added a huge FIXME. ↩

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). ↩

[fmease]

@bors try

[bors]

⌛ Trying commit 5c245de with merge de39175...

[bors]

☀️ Try build successful - checks-actions
Build commit: de39175 (de39175d9e0f63ff8967b81f9639ba28d11ae6ef)

[fmease]

@craterbot check

[craterbot]

👌 Experiment pr-135331 created and queued.
🤖 Automatically detected try build de39175
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-135331 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-135331 is completed!
📊 117 regressed and 36 fixed (566362 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[Skgland]

Based on running Crater Analysis on this crater report
110 out of 117 build failed (unknown) regressions appear spurious caused by running out of disk space, i.e. their logs contain the string no space left on device.
The remaining seven appear to be spurious as well, based on manual review of the logs.

full automated report

Regressed: 117
build failed(unknown): 117
----------------------------------
Results:
no-space: 110
----------------------------------
sum: 110
others: 7
----------------------------------
[
    (
        "ceronman.writing-a-c-compiler.ce987db61026febea0e12806e99932b735808d61",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/gh/ceronman.writing-a-c-compiler",
    ),
    (
        "benrussell.simple_open-rs.feb28e8321d6c3db2cd5b20a6c009c70db767118",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/gh/benrussell.simple_open-rs",
    ),
    (
        "dennisoelkers.brghtnss.43a8295abe3b93dfc257f7908710ef7bb4d2675e",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/gh/dennisoelkers.brghtnss",
    ),
    (
        "gauteh.hidefix.5569aa88689b7dd1867354103e0485894b0d06ec",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/gh/gauteh.hidefix",
    ),
    (
        "smasher164.judgefmt.945d1d88d4083018bcd997df019a03656bc24865",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/gh/smasher164.judgefmt",
    ),
    (
        "pillow-routing-0.4.2",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/reg/pillow-routing-0.4.2",
    ),
    (
        "tree-sitter-po-0.0.1",
        "try%23de39175d9e0f63ff8967b81f9639ba28d11ae6ef/reg/tree-sitter-po-0.0.1",
    ),
]

[BoxyUwU]

Can we open PRs against the affected crates? I imagine it'd be trivial to do so and there arent that many crates either

[fmease]

I already did so back in January as mentioned in the PR description:

I immediately sent downstream PRs: Gui-Yom/turbo-metrics#14, ireina7/summon#1 (however, the owners have showed no reaction so far).

[jackh726]

This seems fine to me, but imo is more of @rust-lang/lang than types, given that it's just a user-visible change of "do we allow ?Sized bounds where they're not meaningful" and either choice doesn't really change anything about the implementation.

[lcnr]

Hmm, I see your point here. We landed #135841 as a pure T-types FCP with a T-lang ping in #135841 (comment) 🤔

To me it feels slightly less clear cut than e.g. a decision about the syntax of such opt-out bounds 🤔 Deciding how / whether to handle where-bounds which are meaningless/incorrect is certainly at the intersection of Types and Lang, though I don't think I would have complained if we originally started this as a pure Lang FCP.

If T-lang minds I am open to give this decision over to them.

[traviscross]

We're fully caught up on nominations, so we should get to it this Wednesday. If you cancel the FCP, I'll restart immediately, as it does seem clearly desirable, and I'd expect it to sail through.

[lcnr]

@rfcbot fcp cancel

[rfcbot]

@lcnr proposal cancelled.

[traviscross]

@rust-lang/lang: This is about rejecting code like this:

fn f<T>() where T: Trait<Ty: ?Sized> {}
trait Trait { type Ty; }

We already reject this:

fn f<T>() where T: Trait, T::Ty: ?Sized {} //~ ERROR
trait Trait { type Ty; }

The crater run is apparently clean.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[lcnr]

The crater run is apparently clean.

except for 2 hobby projects only on GitHub for which @fmease opened fixes back in January which have since been ignored.