Default sizedness bounds were not being added to
`explicit_super_predicates_of` and `explicit_implied_predicates_of`
which meant that a trait bound added to a associated type projection
would be missing the implied predicate of the default sizedness
supertrait of that trait.
An unexpected consequence of this change was that the check for multiple
principals was now finding an additional `MetaSized` principal when
eagerly expanding trait aliases. Instead of special-casing trait aliases
as different from traits and not adding a `MetaSized` supertrait to trait
aliases, filter out `MetaSized` when lowering `dyn Trait`.
Further tighten up relaxed bounds
Follow-up to rust-lang/rust#142693, rust-lang/rust#135331 and rust-lang/rust#135841.
Fixesrust-lang/rust#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.
No longer require that we prove that the predicates of aliases hold when
checking the well-formedness of the alias. This permits more uses of GATs
and changes the output of yet more tests.
For sizedness, default and auto trait predicates, now prefer non-param
candidates if any exist. As these traits do not have generic parameters,
it never makes sense to prefer an non-alias candidate, as there can
never be a more permissive candidate.
* 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)
As a temporary measure while a proper fix for
`tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs`
is implemented, make `MetaSized` obligations always hold. In effect,
temporarily reverting the `sized_hierarchy` feature. This is a small
change that can be backported.
As a performance optimization, skip elaborating the supertraits of
`Sized`, and if a `MetaSized` obligation is being checked, then look for
a `Sized` predicate in the parameter environment. This makes the
`ParamEnv` smaller which should improve compiler performance as it avoids
all the iteration over the larger `ParamEnv`.
This test case is a reduction from the `hwc` crate on GitHub, following a
crater run. It passes with the next solver but fails on the current
solver due to a known limitation of the current solver. It starts fails
on the current solver with the `sized_hierarchy` changes because `?Sized`
is now a proper bound.
When printing impl headers in a diagnostic, the compiler has to account
for `?Sized` implying `MetaSized` and new `MetaSized` and `PointeeSized`
bounds.
Opting-out of `Sized` with `?Sized` is now equivalent to adding a
`MetaSized` bound, and adding a `MetaSized` or `PointeeSized` bound
is equivalent to removing the default `Sized` bound - this commit
implements this change in `rustc_hir_analysis::hir_ty_lowering`.
`MetaSized` is also added as a supertrait of all traits, as this is
necessary to preserve backwards compatibility.
Unfortunately, non-global where clauses being preferred over item bounds
(where `PointeeSized` bounds would be proven) - which can result in
errors when a `PointeeSized` supertrait/bound/predicate is added to some
items. Rather than `PointeeSized` being a bound on everything, it can
be the absence of a bound on everything, as `?Sized` was.
Expand the automatic implementation of `MetaSized` and `PointeeSized` so
that it is also implemented on non-`Sized` types, just not `ty::Foreign`
(extern type).
