don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
Make slice comparisons const
This needed a fix for `derive_const`, too, as it wasn't usable in libcore anymore as trait impls need const stability attributes. I think we can't use the same system as normal trait impls while `const_trait_impl` is still unstable.
r? ```@fee1-dead```
cc rust-lang/rust#143800
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.
* 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)
trait_sel: `MetaSized` always holds temporarily
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.
cc rust-lang/rust#143992
r? ```@lcnr```
Dont collect assoc ty item bounds from trait where clause for host effect predicates
For background, we uplift `where Self::Assoc: Trait` bounds in a trait's where clauses into *item bounds* on `type Assoc;`. This is because before we *had* syntactical item bounds, users would express their item bounds like so.
Let's opt out of doing this same behavior for `HostEffect` predicates like `where Self::Assoc: [const] Trait`. I left a comment in the code:
```rust
// FIXME(const_trait_impl): We *could* uplift the
// `where Self::Assoc: [const] Trait` bounds from the parent trait
// here too, but we'd need to split `const_conditions` into two
// queries (like we do for `trait_explicit_predicates_and_bounds`)
// since we need to also filter the predicates *out* of the const
// conditions or they lead to cycles in the trait solver when
// utilizing these bounds. For now, let's do nothing.
```
As an aside, this was an ICE that was only triggerable when building libraries and not binaries because we never were calling `tcx.ensure_ok().explicit_implied_const_bounds(def_id);` on associated types like we should have been. I adjusted the calls to `ensure_ok` to make sure this happens, so we catch bugs like this in the future more easily.
As another aside, I fixed the bound uplifting logic for *always const* predicates, since those act like normal clauses and have no notion of conditional constness.
r? ```@oli-obk``` ```@fee1-dead``` or anyone really
Fixesrust-lang/rust#133275
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.
Preserve constness in trait objects up to hir ty lowering
r? ``@compiler-errors``
While we don't support `dyn const Trait`, we can at least also inform the user that `const Trait` is only legal for `#[const_trait] trait Trait {}`
Retire hir::*ItemRef.
This information was kept for various places that iterate on HIR to know about trait-items and impl-items.
This PR replaces them by uses of the `associated_items` query that contain pretty much the same information.
This shortens many spans to just `def_span`, which can be easier to read.
constify `From` and `Into`
tracking issue rust-lang/rust#143773
r? ``````@fee1-dead``````
I did not mark any impls elsewhere as `const`, those can happen on their own timeframe and don't need to be part of this MVP. But if there are some core ones you think should be in there I'll happily add them, just couldn't think of any
`tests/ui`: A New Order [26/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ````@tgross35````
New tracking issues for const_ops and const_cmp
Let's do a clean start with new tracking issues to avoid mixing things up with the previous constification.
I assume the fact that the `PartialEq` *trait* and *impls* used different feature names was a mistake (the feature name on the impl is entirely irrelevant anyway).
Part of https://github.com/rust-lang/rust/issues/143800, https://github.com/rust-lang/rust/issues/143802
r? ``@oli-obk``
`tests/ui`: A New Order [28/28] FINAL PART
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
Constify `Fn*` traits
r? `@compiler-errors` `@fee1-dead`
this should unlock a few things. A few `const_closures` tests have broken even more than before, but that feature is marked as incomplete anyway
cc rust-lang/rust#67792
`tests/ui`: A New Order [23/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
When a trait bound fails due to the Self type parameter, adjust_fulfillment_errors
now correctly points to the corresponding function argument instead of incorrectly
pointing to other arguments.
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Most macro tests use `macro` in the name, making it easy to find and run
tests relevant to macros. However, a few use `mbe` instead. Rename those
to say `macro`.
`tests/ui`: A New Order [25/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
`tests/ui`: A New Order [22/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
