Enabling a tied feature should not enable the other feature
automatically. This was fixed by something in rust-lang#128796, probably rust-lang#128221
or rust-lang#128679.

`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for
checking if tied target features were partially enabled. This commit
consolidates these checks into `rustc_codegen_ssa` in the
`codegen_fn_attrs` query, which also is run pre-monomorphisation for
each function, which ensures that this check is run for unused functions,
as would be expected.

…mpatible"

LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.

…n, r=wesleywiser

codegen_ssa: consolidate tied target checks

Fixes rust-lang#105110.
Fixes rust-lang#105111.

`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for checking if tied target features were partially enabled. This PR consolidates these checks into `rustc_codegen_ssa` in the `codegen_fn_attrs` query, which also is run pre-monomorphisation for each function, which ensures that this check is run for unused functions, as would be expected.

Also adds a test confirming that enabling one tied feature doesn't imply another - the appropriate error for this was already being emitted. I did a bisect and narrowed it down to two patches it was likely to be - something in rust-lang#128796, probably rust-lang#128221 or rust-lang#128679.

…, r=workingjubilee

Stabilize const `{slice,array}::from_mut`

This PR stabilizes the following APIs as const stable as of rust `1.83`:
```rs
// core::array
pub const fn from_mut<T>(s: &mut T) -> &mut [T; 1];

// core::slice
pub const fn from_mut<T>(s: &mut T) -> &mut [T];
```
This is made possible by `const_mut_refs` being stabilized (yay).

Tracking issue: rust-lang#90206

rustc_target: Add sme-b16b16 as an explicit aarch64 target feature

LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.

Resolves rust-lang#129894.

…stebank

Don't check unsize goal in MIR validation when opaques remain

Similarly to `mir_assign_valid_types`, let's just skip when there are opaques. Fixes rust-lang#130921.

…in-traits, r=spastorino

Precise capturing in traits

This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work.

Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though.

I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs.

r? types

Tracking issue:
* rust-lang#130044

…zkan

Match std `RUSTFLAGS` for host and target for `mir-opt` test suite to fix double std build/rebuilds

Previously the bootstrap compiletest `Step::run` flow had:

```rs
// ensure that `libproc_macro` is available on the host.
builder.ensure(compile::Std::new(compiler, compiler.host));

// ...

if suite == "mir-opt" {
    builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, target));
} else {
    builder.ensure(compile::Std::new(compiler, target));
}
```

This can cause unnecessary std rebuilds (even on the same invocation) because if host == target then `builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, target))` will have different `RUSTFLAGS` than `builder.ensure(compile::Std::new(compiler, compiler.host))`.

This PR fixes that by matching up std `RUSTFLAGS` if the test suite is `mir-opt`:

```rs
if suite == "mir-opt" {
    builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, compiler.host));
} else {
    builder.ensure(compile::Std::new(compiler, compiler.host));
}
```

This is a short-term fix, the better fix is to enforce how `RUSTFLAGS` are handled as described in rust-lang#131437 (comment).

Fixes rust-lang#131437.

…ouxu

add test infra to explicitely test rustc with autodiff/enzyme disabled

I assume this is not what you want for now, but I'll update the PR once I understand how the ignore- directives work.

To summarize the situation, we want a feature gate test where we don't enable the autodiff feature using `#![feature(autodiff)]`. There are two situations.
1) We have a rustc which was build without autodiff support (current default): It gives one error about the feature being needed and one error about this rustc version being build without autodiff support.
2) We have a rustc which was build with autodiff support (i.e. for now a custom build): It gives one error about the feature being needed.

We have a `//````@needs-enzyme````` directive which we can use in revisions for the second case.
However, we have no way to specify that needs-enzyme implies that the second error should not be seen.
This ads a way of passing the following test:
```
//@ revisions: has_support no_support
//````@[has_support]```` needs-enzyme
//````@[no_support]```` needs-enzyme-disabled

#![crate_type = "lib"]

#[autodiff(dfoo, Reverse)]
//[has_support]~^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~^^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~| ERROR this rustc version does not support autodiff
fn foo() {}
```
Cherry picking this PR to my frontend pr makes the test above pass in both configurations (enzyme=true/false in config.toml).
I'm open to other changes that make this testcase pass.

r? ````@jieyouxu````

Tracking:

- rust-lang#124509

…mpat-2, r=jieyouxu

Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"

Follow-up to rust-lang#130826.
Part of rust-lang#130852.

1. 1st commit: Fix stupid oversights. Should've been part of rust-lang#130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).

…h, r=jieyouxu

Avoid redundant sysroot additions to `PATH` when linking

Currently, `rustc` prepends `$HOME/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin` to the `PATH` three times before invoking the linker, which is unnecessary, once should be enough.

Spotted this while trying to get `-Clinker-flavor=gcc` and `-Clinker-flavor=ld` closer together, not really important.

````@rustbot```` A-linkage