rust/tests/ui/unsized, branch perf-tmp

On E0277, point at type that doesn't implement bound

2025-08-22T17:55:15+00:00

When encountering an unmet trait bound, point at local type that doesn't implement the trait: ``` error[E0277]: the trait bound `Bar: Foo` is not satisfied --> $DIR/issue-64855.rs:9:19 | LL | pub struct Bar(::Type) where Self: ; | ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound | help: the trait `Foo` is not implemented for `Bar` --> $DIR/issue-64855.rs:9:1 | LL | pub struct Bar(::Type) where Self: ; | ^^^^^^^^^^^^^^^^^ ```

Rollup merge of #135331 - fmease:ban-assoc-ty-unbounds, r=lcnr

2025-08-11T08:22:31+00:00

Reject relaxed bounds inside associated type bounds (ATB) **Reject** relaxed bounds — most notably `?Sized` — inside associated type bounds `TraitRef`. This was previously accepted without warning despite being incorrect: ATBs are *not* a place where we perform *sized elaboration*, meaning `TraitRef` does *not* elaborate to `TraitRef` 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 https://github.com/rust-lang/rust/pull/135841#pullrequestreview-2619462717 — 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` despite T-types's ruling established in the FCP'ed rust-lang/rust#135841). This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found ([report](https://github.com/rust-lang/rust/pull/135331#issuecomment-2585330783), [its analysis](https://github.com/rust-lang/rust/pull/135331#issuecomment-2585356422)). [However a contributor manually found two occurrences](https://github.com/rust-lang/rust/issues/135229#issuecomment-2581832852) of `TraitRef` in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: https://github.com/Gui-Yom/turbo-metrics/pull/14, https://github.com/ireina7/summon/pull/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 rust-lang/rust#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).

Rehome tests/ui/issues/ tests [1/?]

2025-07-24T21:01:44+00:00

Reject relaxed bounds inside associated type bounds

2025-07-20T11:30:25+00:00

Don't reject multiple relaxed bounds, reject duplicate ones.

2025-07-18T10:24:56+00:00

Having multiple relaxed bounds like `?Sized + ?Iterator` is actually *fine*. We actually want to reject *duplicate* relaxed bounds like `?Sized + ?Sized` because these most certainly represent a user error. Note that this doesn't mean that we accept more code because a bound like `?Iterator` is still invalid as it's not relaxing a *default* trait and the only way to define / use more default bounds is under the experimental and internal feature `more_maybe_bounds` plus `lang_items` plus unstable flag `-Zexperimental-default-bounds` (historical context: for the longest time, bounds like `?Iterator` were actually allowed and lead to a hard warning). Ultimately, this simply *reframes* the diagnostic. The scope of `more_maybe_bounds` / `-Zexperimental-default-bounds` remains unchanged as well.

Reword diagnostic about relaxing non-`Sized` bound

2025-07-18T10:13:30+00:00

* The phrasing "only does something for" made sense back when this diagnostic was a (hard) warning. Now however, it's simply a hard error and thus completely rules out "doing something". * The primary message was way too long * The new wording more closely mirrors the wording we use for applying other bound modifiers (like `const` and `async`) to incompatible traits. * "all other traits are not bound by default" is no longer accurate under Sized Hierarchy. E.g., traits and assoc tys are (currently) bounded by `MetaSized` by default but can't be relaxed using `?MetaSized` (instead, you relax it by adding `PointeeSized`). * I've decided against adding any diagnositic notes or suggestions for now like "trait `Trait` can't be relaxed as it's not bound by default" which would be incorrect for `MetaSized` and assoc tys as mentioned above) or "consider changing `?MetaSized` to `PointeeSized`" as the Sized Hierarchy impl is still WIP)

Reword diagnostics about relaxed bounds in invalid contexts

2025-07-18T10:13:19+00:00

AST lowering: More robustly deal with relaxed bounds

2025-07-18T01:13:21+00:00

Unconditionally run `check_item_type` on all items

2025-06-30T08:06:08+00:00

Unimplement unsized_locals

2025-06-12T23:16:36+00:00