Skip to content

Rustc pull update - #3038

Merged
tshepang merged 29 commits into
mainfrom
tshepang/pull
Sep 30, 2026
Merged

tshepang merged 29 commits into
mainfrom
tshepang/pull

Conversation

@tshepang

Copy link
Copy Markdown
Member

Merge ref '7d2cd0fbc092' from rust-lang/rust

Pull recent changes from https://github.com/rust-lang/rust via Josh.

Previous upstream ref: rust-lang/rust@56fad88
New upstream ref: rust-lang/rust@7d2cd0f
Filtered ref: 9c779ca
Upstream diff: rust-lang/rust@56fad88...7d2cd0f

This merge was created using https://github.com/rust-lang/josh-sync.

JonathanBrouwer and others added 29 commits September 21, 2026 17:34
Set target-abi module flag for LoongArch targets

Like the earlier RISC-V fix (rust-lang/rust#123612), emit the "target-abi" module flag for LoongArch so that LTO correctly picks up the ABI.

This follows the recent LLVM change (llvm/llvm-project#223647) that relies on the module flag for proper TargetMachine / data-layout handling during LTO on LoongArch.
Make the last non-breaking box impl generalizations

Follow-up to rust-lang/rust#161946

r? clarfonthey
…uwer

Rollup of 5 pull requests

Successful merges:

 - rust-lang/rust#162948 (Set target-abi module flag for LoongArch targets)
 - rust-lang/rust#162600 (Make the last non-breaking box impl generalizations)
 - rust-lang/rust#163031 (Use newer `make` version when building GCC)
 - rust-lang/rust#163054 (Use verbose suggestion for method written as function)
 - rust-lang/rust#163073 (Expand docs on `rustc_abi::Variants`)
Add regression tests for issues marked fixed-by-next-solver (1/N)

Note that while these issues are marked `fixed-by-next-solver`, some of them also pass with the old solver now.

Fixes rust-lang/rust#90950
Fixes rust-lang/rust#102580
Fixes rust-lang/rust#134312
Fixes rust-lang/rust#134370
Fixes rust-lang/rust#141478
Add some docs for each non-query DepKind

Most of these non-query dep-kinds lack any docs, and the docs that do exist are not very accurate.

These new docs should hopefully be more useful, though they cannot claim to be exhaustive.

"Anonymous tasks" remain under-documented, but that's beyond the scope of this particular PR.

---

This is an internal-docs-only change; there should be no change to compiler behaviour.
bootstrap: print when we are testing in Miri

It can be a bit hard to tell form the log that things are running in Miri. This should make it more clear.
rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to a6d7ad1.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost
…uwer

Rollup of 4 pull requests

Successful merges:

 - rust-lang/rust#162137 (Add regression tests for issues marked fixed-by-next-solver (1/N))
 - rust-lang/rust#162889 (Add some docs for each non-query DepKind)
 - rust-lang/rust#163117 (bootstrap: print when we are testing in Miri)
 - rust-lang/rust#163123 (rustc-dev-guide subtree update)
Fix suggestion for mutability mismatch between trait def and trait impl in 2015 edition



This code:

```rust
mod bar {
    pub struct X;
}

pub trait A {
    fn f(x: &mut bar::X);
}

mod b {
    pub struct X;

    impl crate::A for X {
        fn f(_x: &crate::bar::X) {}
    }
}
```

emits:

```console
error[E0053]: method `f` has an incompatible type for trait
  --> foo.rs:13:18
   |
13 |         fn f(_x: &crate::bar::X) {}
   |                  ^^^^^^^^^^^^^^ types differ in mutability
   |
note: type in trait
  --> foo.rs:6:13
   |
 6 |     fn f(x: &mut bar::X);
   |             ^^^^^^^^^^^
   = note: expected signature `fn(&mut X)`
              found signature `fn(&X)`
help: change the parameter type to match the trait
   |
13 -         fn f(_x: &crate::bar::X) {}
13 +         fn f(_x: &mut bar::X) {}
   |
```

Which is wrong. This PR fixes it. However the `Ty` doesn't hold a context (or at least not a correct one) allowing to have a correct path to the `X` type. So instead, in case of a mutability mismatch, we (try to) retrieve the code snippet, and remove/add the `mut` keyword. If we fail to, we revert to the current behaviour.

r? @mejrs
…08, r=antoyo

`rustc_codegen_gcc` subtree update



r? antoyo
Defer extra liveness calculation for Polonius Alpha



Best reviewed by commit.

This moves liveness calculation of NLL-boring/Polonius-relevant locals to be lazy. This allows us to skip unnecessary work.

r? lqd
Enable `tests/debuginfo` on `test-aarch64-gnu-llvm-21`



This should allow `tests/debuginfo` to run the LLDB tests in PR CI. This should run `basic-types` and `pretty-std` which both contain `repr` directives.

r? @jieyouxu @Kobzol
rename GCA features

fixes rust-lang/project-const-generics#114

We would like to publish posts soon that GCE is dying and GCA is the future. As part of that, we want the feature gates/etc. to be in their final-ish shape. We discussed a lot of naming bikesheds in the zulip thread [#project-const-generics > talkies at last @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/near/620368825), namely:

- `min_generic_const_args` -> `gca_min_const_items`
- `generic_const_args` -> `gca_const_items`
- `macroless_generic_const_args` -> `gca_macroless_args`
- `macroless_const_item_generic_const_args` -> `gca_macroless_items`

things that were discussed in that Zulip thread, but are not part of this PR:

- `gca_adts` and/or `gca_arrays` (the feature is not created yet)
  - the `DirectConstArgContext` enum is in a vaguely awkwardly named spot after this PR. I intend to clean it up as part of creating the `gca_adts` feature (perhaps turning it into a bitflags for allowed syntax, or something)
- renaming the `direct_const_arg!` macro to `gca!` - this was done in rust-lang/rust#163198
- deleting `type const`, introducing `#[always_gca]` - this was done in rust-lang/rust#162517

r? @BoxyUwU
Fix docs in core::slice

- Add a comma after the conditional clause in `split_at_checked` and `split_at_mut_checked`
- "equals to" -> "equals" in `swap`
Additional NonZero conversions



ACP: rust-lang/libs-team#145

Requires FCP due to insta-stable APIs added:

```rust
// can't be done generically; compiler can't infer that ZeroablePrimitive is sealed for coherence reasons
impl From<&NonZero<uN>> for &uN;
impl From<&NonZero<iN>> for &iN;
impl From<&NonZero<usize>> for &usize;
impl From<&NonZero<isize>> for &isize;
impl From<&NonZero<char>> for &char;

// excluded due to typechecking bug, but left commented out in code
// impl<T> From<&[NonZero<T>]> for &[T] where T: ZeroablePrimitive;

// rest are generic
impl<T, const N: usize> From<[NonZero<T>; N]> for [T; N] where T: ZeroablePrimitive;
impl<T> TryFrom<&T> for &NonZero<T> where T: ZeroablePrimitive;
impl<T> TryFrom<&[T]> for &[NonZero<T>] where T: ZeroablePrimitive;
impl<T, const N: usize> TryFrom<[T; N]> for [NonZero<T>; N] where T: ZeroablePrimitive;
```

Note that the `Error` for the `TryFrom` implementations is `TryFromIntError` to match the similar impls.

r? rust-lang/libs-api
Stabilize `funnel_shifts` (including `const`)

`funnel_shl` and `funnel_shr` have been around for close to a year, the unchecked versions for a number of months. These are reasonably small and uncontroversial, and it can be tricky to get similar performance with a fallback; stabilize them here.

Newly stable API:

```rust
impl {u8, u16, u32, u64, u128, usize} {
    pub const fn funnel_shl(self, right: Self, shift: u32) -> Self;
    pub const fn funnel_shr(self, right: Self, shift: u32) -> Self;

    pub const unsafe fn unchecked_funnel_shl(self, right: Self, shift: u32) -> Self;
    pub const unsafe fn unchecked_funnel_shr(self, right: Self, shift: u32) -> Self;
}
```

The tracking issue also mentions a `wrapping_` version but it has not been implemented.

Closes: rust-lang/rust#145686 (tracking issue, wrapping versions will need a new issue)
Add support for -Zsanitizer-cfi-minimal-runtime

For production use, we should only link in the ubsan_minimal runtime,
instead of the complete ubsan runtime. This adds support for both
cfi-recover and cfi-diag to use the minimal runtime when
`-Zsanitizer-cfi-minimal-runtime` is specified.

This also includes tests, to ensure the flag can only be used if either
cfi-recover or cfi-diag is enabled, it doesn't disrupt the original
behavior, and links in the correct runtime when specified.

cc @1c3t3a

?r rcvalle
…enkov

do not complain about unstable target features on nightly

This was brought up in rust-lang/rust#162235 (comment): we currently print a warning on nightly saying that using an unstable target feature will become a hard error. That's a mistake.

We could either remove the part of the warning that talks about it becoming a hard error, or we could just hide the warning entirely for unstable features on nighty. I went for the latter -- nightly is meant for experimentation with those features so having un-silenceable warnings is not great.

Cc @workingjubilee
Add `stable_rustc` helper in `run-make-support`

To help with rust-lang/rust#162848 and https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/626329887.

For rust-lang/rust#162848, I need to avoid passing `-Zthreads` when the compiler is supposed to act like `stable`. This refactoring makes that simpler; I will only add that flag to `Rustc::new` and not `Rustc::stable`.

r? jieyouxu
…trochenkov

Allow using different index types when reading and writing to tables

Make tables of metadata two-sided: one can write with one index type and read with another, as long as both those types are indexes. That will be used in rust-lang/rust#163321 when we will have `LocalDefIndex` or similar type.

r? @petrochenkov
…-kruppe

Stabilize vec_try_remove

Closes rust-lang/rust#146954 , which is has [completed its FCP with disposition to merge](rust-lang/rust#146954 (comment)).

Hello, this is my first contribution to Rust! I was programming for fun this weekend and I was surprised that this wasn't stabilized, so I thought I would try to contribute.

Disclosure: I am making this PR in my capacity as a Canonical employee.

No LLMs were harmed in the making of this pull request.
Rollup of 9 pull requests

Successful merges:

 - rust-lang/rust#161015 (Stabilize `funnel_shifts` (including `const`))
 - rust-lang/rust#161712 (Stabilize `Result::into_{ok,err}`)
 - rust-lang/rust#162493 (Add support for -Zsanitizer-cfi-minimal-runtime)
 - rust-lang/rust#163427 (implement #![feature(gca_adts)])
 - rust-lang/rust#163390 (add `automatically_derived` attribute documentation)
 - rust-lang/rust#163428 (do not complain about unstable target features on nightly)
 - rust-lang/rust#163444 (Add `stable_rustc` helper in `run-make-support`)
 - rust-lang/rust#163447 (Allow using different index types when reading and writing to tables)
 - rust-lang/rust#163459 (Stabilize vec_try_remove)
Specialize `advance_back_by` like the forward version

We specialized `advance_by` in rust-lang/rust#141086, so it makes sense to have
`advance_back_by` use the same trick in reverse, i.e. `try_rfold`.

This also updates `nth_back` to mirror `nth`, and the rest of the
`DoubleEndedIterator` methods already match `Iterator`.
This updates the rust-version file to 7d2cd0fbc092625ea371da704f15f80216d2220e.
Pull recent changes from https://github.com/rust-lang/rust via Josh.

Previous upstream ref: rust-lang/rust@56fad88
New upstream ref: rust-lang/rust@7d2cd0f
Filtered ref: 9c779ca
Upstream diff: rust-lang/rust@56fad88...7d2cd0f

This merge was created using https://github.com/rust-lang/josh-sync.
@rustbot

rustbot commented Sep 30, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using r? rustc-dev-guide or r? <username>.

@rustbot rustbot added the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Sep 30, 2026
@tshepang
tshepang merged commit 8ae6c25 into main Sep 30, 2026
4 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Sep 30, 2026
@tshepang
tshepang deleted the tshepang/pull branch September 30, 2026 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants