Skip to content

Conversation

@workflows-miri
Copy link

Merge ref '8401398e1f14' from rust-lang/rust

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

Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8
Filtered ref: 9c097c0
Upstream diff: rust-lang/rust@ceb7df7...8401398

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

pitaj and others added 30 commits October 25, 2025 14:30
Update cargo submodule

22 commits in 6368002885a04cbeae39a82cf5118f941559a40a..445fe4a68f469bf936b2fd81de2c503b233a7f4f
2025-10-31 14:31:52 +0000 to 2025-11-07 18:08:19 +0000
- fix(depinfo): prevent invalid trailing backslash on Windows (rust-lang/cargo#16223)
- refactor: Remove lazycell (rust-lang/cargo#16224)
- refactor: extract ConfigValue to its own module (rust-lang/cargo#16222)
- fix(config): non-mergeable list from cli should take priority (rust-lang/cargo#16220)
- fix(compile): build.warnings=deny shouldn't block hard warnings (rust-lang/cargo#16213)
- fix: display absolute path in the `missing in PATH` warning (rust-lang/cargo#16125)
- fix: non-mergeable list from config cli merge the same way  (rust-lang/cargo#16219)
- docs(contrib): Link out to rustc diagnostic style guide (rust-lang/cargo#16216)
- fix: Remove build-plan (rust-lang/cargo#16212)
- Add native completions for `--package` on various commands (rust-lang/cargo#16210)
- fix(completions): don't wrap completion item help in parenthesis (rust-lang/cargo#16215)
- refactor(locking): Make disabling locking on NFS mounts explicit (rust-lang/cargo#16177)
- docs(unstable): Move compile-time-deps out of Stabilized section (rust-lang/cargo#16211)
- docs(ref): Rename DEP_NAME_KEY to DEP_LINKS_KEY (rust-lang/cargo#16205)
- feat(build-analysis): emit rebuild reason log entry (rust-lang/cargo#16203)
- chore: Update dependencies (rust-lang/cargo#16200)
- chore(deps): update cargo-semver-checks to v0.45.0 (rust-lang/cargo#16190)
- chore(deps): update msrv (rust-lang/cargo#16178)
- refactor: embed deserialize validation logic in ProgressConfig (rust-lang/cargo#16194)
- refactor(gctx): extract config schema to a module (rust-lang/cargo#16195)
- chore: bump to 0.94.0; update changelog (rust-lang/cargo#16191)
- chore(deps): update rust crate gix to 0.74.0 (rust-lang/cargo#16186)

r? ghost
Add -Zannotate-moves for profiler visibility of move/copy operations (codegen)

**Note:** this is an alternative implementation of rust-lang/rust#147206; rather than being a MIR transform, it adds the annotations closer to codegen. It's functionally the same but the implementation is lower impact and it could be more correct.

---

This implements a new unstable compiler flag `-Zannotate-moves` that makes move and copy operations visible in profilers by creating synthetic debug information. This is achieved with zero runtime cost by manipulating debug info scopes to make moves/copies appear as calls to `compiler_move<T, SIZE>` and `compiler_copy<T, SIZE>` marker functions in profiling tools.

This allows developers to identify expensive move/copy operations in their code using standard profiling tools, without requiring specialized tooling or runtime instrumentation.

The implementation works at codegen time. When processing MIR operands (`Operand::Move` and `Operand::Copy`), the codegen creates an `OperandRef` with an optional `move_annotation` field containing an `Instance` of the appropriate profiling marker function. When storing the operand, `store_with_annotation()` wraps the store operation in a synthetic debug scope that makes it appear inlined from the marker.

Two marker functions (`compiler_move` and `compiler_copy`) are defined in `library/core/src/profiling.rs`. These are never actually called - they exist solely as debug info anchors.

Operations are only annotated if:
   - We're generating debug info and the feature is enabled.
   - Meets the size threshold (default: 65 bytes, configurable via `-Zannotate-moves=SIZE`), and is non-zero
   - Has a memory representation

This has a very small size impact on object file size. With the default limit it's well under 0.1%, and even with a very small limit of 8 bytes it's still ~1.5%. This could be enabled by default.
Add LLVM realtime sanitizer

This is a new attempt at adding the [LLVM real-time sanitizer](https://clang.llvm.org/docs/RealtimeSanitizer.html) to rust.

Previously this was attempted in rust-lang/rfcs#3766.

Since then the `sanitize` attribute was introduced in rust-lang/rust#142681 and it is a lot more flexible than the old `no_santize` attribute. This allows adding real-time sanitizer without the need for a new attribute, like it was proposed in the RFC. Because i only add a new value to a existing command line flag and to a attribute i don't think an MCP is necessary.

Currently real-time santizer is usable in rust code with the [rtsan-standalone](https://crates.io/crates/rtsan-standalone) crate. This downloads or builds the sanitizer runtime and then links it into the rust binary.

The first commit adds support for more detailed sanitizer information.
The second commit then actually adds real-time sanitizer.
The third adds a warning against using real-time sanitizer with async functions, cloures and blocks because it doesn't behave as expected when used with async functions. I am not sure if this is actually wanted, so i kept it in a seperate commit.
The fourth commit adds the documentation for real-time sanitizer.
Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro

closes rust-lang/rust#145649
closes rust-lang/rust#135413
cc: rust-lang/rust#130869
reference PR: rust-lang/reference#1972

# Stabilization report

## Summary

This PR stabilizes the following s390x target features:

- `vector`
- `vector-enhancements-1`
- `vector-enhancements-2`
- `vector-enhancements-3`
- `vector-packed-decimal`
- `vector-packed-decimal-enhancement`
- `vector-packed-decimal-enhancement-2`
- `vector-packed-decimal-enhancement-3`
- `nnp-assist`
- `miscellaneous-extensions-2`
- `miscellaneous-extensions-3`
- `miscellaneous-extensions-4`

Additionally, it stabilizes the `std::arch::is_s390x_feature_detected!` macro itself and stably accepts the target features listed above.

## Tests & ABI details

Only the `vector` target feature changes the ABI, much like e.g. `avx2` it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively:

- [tests/assembly-llvm/s390x-vector-abi.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs)
- [tests/codegen-llvm/s390x-simd.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/assembly-llvm/s390x-vector-abi.rs)
- [tests/ui/abi/simd-abi-checks-s390x.rs ](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs )

The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled.

## Implementation history

For `is_s390x_feature_detected!`:

- rust-lang/stdarch#1699
- rust-lang/rust#138275
- rust-lang/stdarch#1720
- rust-lang/stdarch#1832

For `vector` and friends

- rust-lang/rust#127506
- rust-lang/rust#135630
- rust-lang/rust#141250

## Unresolved questions

There is a fixme in [tests/ui/abi/simd-abi-checks-s390x.rs](https://github.com/rust-lang/rust/blob/22a86f8280becb12c34ee3efd952baf5cf086fa0/tests/ui/abi/simd-abi-checks-s390x.rs):

```
// FIXME: +soft-float itself doesn't set -vector
//`@[z13_soft_float]` compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float
//`@[z13_soft_float]` needs-llvm-components: systemz
```

I'm not sure whether that blocks stabilization?

---

The implementation first extracts the listed target features into their own `s390x_target_feature_vector` rust feature, and then stabilizes that. best reviewed commit-by-commit

r? `@Amanieu`
cc `@uweigand`  `@taiki-e`
…rk-Simulacrum

std_detect: Support run-time detection on OpenBSD using elf_aux_info
Implement SIMD funnel shifts in const-eval/Miri

Split off from rust-lang/rust#147520 with just this change for easier review

r? ```@RalfJung```
Stabilise `as_array` in `[_]` and `*const [_]`; stabilise `as_mut_array` in `[_]` and `*mut [_]`.

Tracking issue: rust-lang/rust#133508

Closes: rust-lang/rust#133508

This PR stabilises the `as_array` and `as_mut_array` associated functions from the `core_slice_as_array` feature gate:

```rust
// core::slice

impl<T> [T] {
    pub const fn as_array<const N: usize>(&self) -> Option<&[T; N]>;

    pub const fn as_mut_array<const N: usize>(&mut self) -> Option<&mut [T; N]>;
}

// core::ptr

impl<T> *const [T] {
    pub const fn as_array<const N: usize>(self) -> Option<*const [T; N]>;
}

impl<T> *mut [T] {
    pub const fn as_mut_array<const N: usize>(self) -> Option<*mut [T; N]>;
}
```

It also updates the feature gates and tracking issues for all items associated with the previous `slice_as_array` tracking issue (including these four that are being stabilised).

~~FCP missing.~~
update isolate_highest_one for NonZero<T>

## Rationale
Let `x = self` and
`m = (((1 as $Int) << (<$Int>::BITS - 1)).wrapping_shr(self.leading_zeros()))`
Then the previous code computed `NonZero::new_unchecked(x & m)`.
Since `m` has exactly one bit set (the most significant 1-bit of `x`), `(x & m) == m`.
Therefore, the masking step was redundant.

The shift is safe and does not need wrapping because:
* `self.leading_zeros() < $Int::BITS` because `self` is non-zero.
* The result of `unchecked_shr` is non-zero, satisfying the `NonZero` invariant. if wrapping happens we would be violating `NonZero` invariants.

why this micro optimization?
the old code was suboptimal it duplicated `$Int`’s isolate_highest_one logic instead of delegating to it. Since the type already wraps `$Int`, either delegation should be used for clarity or, if keeping a custom implementation, it should be optimized as above.
…eGomez

rustdoc: Properly highlight shebang, frontmatter & weak keywords in source code pages and code blocks

Before | After
---|---
<img width="517" height="532" alt="Screenshot 2025-10-28 at 23-21-02 pre rs - source" src="https://github.com/user-attachments/assets/5026761f-c604-4bcc-a699-9e75eb73dff6" /> | <img width="499" height="531" alt="Screenshot 2025-10-28 at 23-21-51 pre rs - source" src="https://github.com/user-attachments/assets/cc8c65e7-e3ad-4e20-a2c3-2623cf799093" />
Fix rust-by-example spanish translation

A spanish translation was added in rust-lang/rust-by-example#1910, but the upstream integration was never added.

```@marioidival,``` I assume you intended for this to go live?
… r=JonathanBrouwer

Fix suggestion for returning async closures

Fixes rust-lang/rust#148493
…ofek

[rustdoc] Replace `print` methods with functions to improve code readability

We have a lot of `print` methods, making it quite tricky to know what the types we're manipulating are.

We did something similar with `Clean` trait a few years ago (the first PR was rust-lang/rust#99638, followed by a lot of them).

Each commit replaces one type for easier review.

r? `````@yotamofek`````
…onathanBrouwer

re-use `self.get_all_attrs` result for pass indirectly attribute

Could be a fix for a potential performance regression reported here rust-lang/rust#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor.

r? ````@JonathanBrouwer```` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)
mgca: Add ConstArg representation for const items

tracking issue: rust-lang/rust#132980
fixes rust-lang/rust#131046
fixes rust-lang/rust#134641

As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.

To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.

We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
Rollup of 10 pull requests

Successful merges:

 - rust-lang/rust#145656 (Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro)
 - rust-lang/rust#147024 (std_detect: Support run-time detection on OpenBSD using elf_aux_info)
 - rust-lang/rust#147534 (Implement SIMD funnel shifts in const-eval/Miri)
 - rust-lang/rust#147540 (Stabilise `as_array` in `[_]` and `*const [_]`; stabilise `as_mut_array` in `[_]` and `*mut [_]`.)
 - rust-lang/rust#147686 (update isolate_highest_one for NonZero<T>)
 - rust-lang/rust#148230 (rustdoc: Properly highlight shebang, frontmatter & weak keywords in source code pages and code blocks)
 - rust-lang/rust#148555 (Fix rust-by-example spanish translation)
 - rust-lang/rust#148556 (Fix suggestion for returning async closures)
 - rust-lang/rust#148585 ([rustdoc] Replace `print` methods with functions to improve code readability)
 - rust-lang/rust#148600 (re-use `self.get_all_attrs` result for pass indirectly attribute)

r? `@ghost`
`@rustbot` modify labels: rollup
Add `overflow_checks` intrinsic

This adds an intrinsic which allows code in a pre-built library to inherit the overflow checks option from a crate depending on it. This enables code in the standard library to explicitly change behavior based on whether `overflow_checks` are enabled, regardless of the setting used when standard library was compiled.

This is very similar to the `ub_checks` intrinsic, and refactors the two to use a common mechanism.

The primary use case for this is to allow the new `RangeFrom` iterator to yield the maximum element before overflowing, as requested [here](rust-lang/rust#125687 (comment)). This PR includes a working `IterRangeFrom` implementation based on this new intrinsic that exhibits the desired behavior.

[Prior discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Ability.20to.20select.20code.20based.20on.20.60overflow_checks.60.3F)
…thanBrouwer

Add correct suggestion for multi-references for self type in method

Currently the suggestion for this code

```rust
fn main() {}

struct A {
    field: i32,
}

impl A {
    fn f(&&self) {}
}
```

looks like this, which is incorrect and missleading

```rust
   Compiling playground v0.0.1 (/playground)
error: expected one of `!`, `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
 --> src/main.rs:8:16
  |
8 |     fn f(&&self) {}
  |                ^ expected one of 9 possible tokens
  |
  = note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: explicitly ignore the parameter name
  |
8 |     fn f(_: &&self) {}
  |          ++
```

So this fixes it and make more correct suggestions

```rust
error: expected one of `!`, `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
 --> /home/gh-Kivooeo/test_/src/main.rs:8:16
  |
8 |     fn f(&&self) {}
  |                ^ expected one of 9 possible tokens
  |
help: `self` should be `self`, `&self` or `&mut self`, please remove extra references
  |
8 -     fn f(&&self) {}
8 +     fn f(&self) {}
```

Implementation is pretty self-documenting, but if you have suggestions on how to improve this (according to current test, which may be not fully covering all cases, this is works very well) or have some funny edge cases to show, I would appreciate it

r? compiler
[DebugInfo] Fix container types failing to find template args

This is a less pervasive (but also less powerful) alternative to rust-lang/rust#144394.

This change *only* provides benefits to container types on MSVC. The TL;DR is that nodes that don't populate/aren't discoverable in the PDB for various reasons are given an alternate lookup path that generates the nodes by acquiring the base-type via some gross string manipulation and then asking clang for the node it wants (e.g. `"ref$<i32>"` -> `"i32"` -> `target.FindFirstType("i32").GetPointerType()` -> `i32 *`, which is a valid type for the container to use)

The before/afters are the same as in the above PR's `*-msvc` LLDB screenshots. This works as a stopgap while the above PR is evaluated, but I think that PR is still a much better solution.
Show packed field alignment in mir_transform_unaligned_packed_ref

Fixes rust-lang/rust#147528

I left the expected padding for the field out of the error message so the message would be the same on all platforms. It also isn't always possible to know the expected alignment, so this makes the message simpler.
Rename `downcast_[ref|mut]_unchecked` -> `downcast_unchecked_[ref|mut]`

## Intent

Renames `downcast_[ref|mut]_unchecked` to `downcast_unchecked_[ref|mut]` because we want to emphasise that it is the downcast that is unsafe, not the aliasing per:

rust-lang/rust#90850 (comment)

## Tracking Issue: rust-lang/rust#90850 (comment)

cc `@marc0246`
…Mark-Simulacrum

Optimize path components iteration on platforms that don't have prefixes

```
OLD

path::bench_path_components_iter 140.20ns/iter +/- 6.08
path::bench_path_file_name 57.62ns/iter +/- 1.62

NEW

path::bench_path_components_iter 126.74ns/iter +/- 1.46
path::bench_path_file_name 47.48ns/iter +/- 2.49
```
Fix rust stdlib build failing for VxWorks

Fixes rust-lang/rust#148125.

O_NOFOLLOW is not supported on VxWorks. All the other defines/functions have been added to libc(rust-lang/libc@0cd5032)
Modify contributor email entries in .mailmap

This adds mailmap entries for duplicates I found in https://thanks.rust-lang.org/rust/all-time/

If I added an entry for you and it is not correct, then please let me know! See the comments at the start of https://github.com/rust-lang/thanks/blob/master/mailmap/src/lib.rs for understanding these entries.

After this gets into the repo, the thanks page will be regenerated within a day, and your double entries will be merged.

cc ````````@aochagavia````````
cc ````````@fasterthanlime````````
cc ````````@jackh726````````
cc ````````@jakubadamw````````
cc ````````@yaahc````````
cc ````````@jackpot51````````
cc ````````@jonhoo````````
cc ````````@marcoieni````````
cc ````````@onur-ozkan````````
cc ````````@rylev````````
cc ````````@willcrichton````````
cc ````````@yoshuawuyts````````
rustc_builtin_macros: rename bench parameter to avoid collisions with user-defined function names

Resolves rust-lang/rust#148275 by preventing name collisions in the `#[bench]` macro.

Previously, a user-defined function named "b" could not be benchmarked because
the macro-generated lambda identity collided with the same name. We now generate
the lambda ident as `__bench_<function_name>`, ensuring it is always distinct
from the user’s function.

Because the prefix is applied recursively (e.g. benchmarking `__bench_b`
produces a lambda ident `__bench___bench_b`), there is no possible function
name that can equal its corresponding lambda ident. This guarantees that
the user can safely bench a function of any valid name without risk of
identifier collision.
…k-simulacrum

constify result unwrap unchecked

constifies unwrap unchecked on result
will make tracking issue if good
Add Allocator proxy impls for Box, Rc, and Arc

This adds to the existing proxy impl for &T.

Fixes rust-lang/wg-allocators#54
…ooeo

`invalid_atomic_ordering`: also lint `update` & `try_update`

Split from rust-lang/rust#148590

Tracking issue for `update` and `try_update`: rust-lang/rust#135894
…diagnostic, r=JonathanBrouwer

Add note for identifier with attempted hygiene violation

Fixes rust-lang/rust#148580

I changed the original test to make sure we are pointing to the right scope.
Zalathar and others added 21 commits November 9, 2025 13:22
Remove eslint-js from npm dependencies

Testing if this unblocks CI.

r? ```@ghost```
Recover `[T: N]` as `[T; N]`

`;` is similar and (keyboard-wise) next to `:`, so a verbose suggestion may help to see the difference.

Parent PR: rust-lang/rust#143905

---
`@rustbot` label +A-parser +A-array +A-diagnostics +A-suggestion-diagnostics +D-papercut
…mann

Remove unused argument `features` from `eval_config_entry`
…ivooeo

Use the current lint note id when parsing `cfg!()`
Rollup of 22 pull requests

Successful merges:

 - rust-lang/rust#128666 (Add `overflow_checks` intrinsic)
 - rust-lang/rust#146305 (Add correct suggestion for multi-references for self type in method)
 - rust-lang/rust#147179 ([DebugInfo] Fix container types failing to find template args)
 - rust-lang/rust#147743 (Show packed field alignment in mir_transform_unaligned_packed_ref)
 - rust-lang/rust#148079 (Rename `downcast_[ref|mut]_unchecked` -> `downcast_unchecked_[ref|mut]`)
 - rust-lang/rust#148084 (Optimize path components iteration on platforms that don't have prefixes)
 - rust-lang/rust#148126 (Fix rust stdlib build failing for VxWorks)
 - rust-lang/rust#148204 (Modify contributor email entries in .mailmap)
 - rust-lang/rust#148279 (rustc_builtin_macros: rename bench parameter to avoid collisions with user-defined function names)
 - rust-lang/rust#148333 (constify result unwrap unchecked)
 - rust-lang/rust#148539 (Add Allocator proxy impls for Box, Rc, and Arc)
 - rust-lang/rust#148601 (`invalid_atomic_ordering`: also lint `update` & `try_update`)
 - rust-lang/rust#148612 (Add note for identifier with attempted hygiene violation)
 - rust-lang/rust#148613 (Switch hexagon targets to rust-lld)
 - rust-lang/rust#148619 (Enable std locking functions on AIX)
 - rust-lang/rust#148644 ([bootstrap] Make `--open` option work with `doc src/tools/error_index_generator`)
 - rust-lang/rust#148649 (don't completely reset `HeadUsages`)
 - rust-lang/rust#148673 (Remove a remnant of `dyn*` from the parser)
 - rust-lang/rust#148675 (Remove eslint-js from npm dependencies)
 - rust-lang/rust#148680 (Recover `[T: N]` as `[T; N]`)
 - rust-lang/rust#148688 (Remove unused argument `features` from `eval_config_entry`)
 - rust-lang/rust#148711 (Use the current lint note id when parsing `cfg!()`)

r? `@ghost`
`@rustbot` modify labels: rollup
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)`

Fixes rust-lang/rust#141301.

<details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary>

Regarding rust-lang/rust#141301 (comment) (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in rust-lang/rust#144004 (comment)).

</details>

r? GuillaumeGomez
Remove `#[const_trait]`

Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute.

r? ```@rust-lang/project-const-traits```
std: use a non-poisoning `RwLock` for the panic hook

The code ignored poison errors using `PoisonError` anyway.
…isable-self-contained-lld, r=Mark-Simulacrum

fix: disable self-contained linker when bootstrap-override-lld is set

Part of rust-lang/rust#148708.

Makes `rust.bootstrap-override-lld` set to `true` or `"external"` disable self-contained linker — actually using linker from one's system.
mgca: Finish implementation of `#[type_const]`

tracking issue: rust-lang/rust#132980
fixes rust-lang/rust#140729
fixes rust-lang/rust#140860

- **Fix `#[type_const]` attribute placement validation**
- **Perform WF-checking on type_const RHS's**
- **Check type_const type is ConstParamTy_ and that RHS matches it**
- **Check that impls of `#[type_const]` consts also have the attr**

r? ```@BoxyUwU```
bootstrap: Render doctest timing reports as text, not JSON

These doctest timing reports were added to libtest/rustdoc in rust-lang/rust#144909, but bootstrap's custom test-output renderer wasn't taught about them, so they were being printed as raw JSON instead.

Before:
```text
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
```

After:
```text
all doctests ran in 0.73s; merged doctests compilation took 0.72s
```

<details>
<summary><b>Detailed before/after in context</b></summary>

## Before

```text
$ x test rustc_mir_transform --doc
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
    Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
   Doc-tests rustc_mir_transform

running 19 tests
iiiiiiiiiiii.......

test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.28ms

running 7 tests
iiiiiii

test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 403.67µs

{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
	finished in 1.505 seconds
Build completed successfully in 0:00:01
```

## After

```text
$ x test rustc_mir_transform --doc
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
    Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
   Doc-tests rustc_mir_transform

running 19 tests
iiiiiiiiiiii.......

test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.12ms

running 7 tests
iiiiiii

test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 395.67µs

all doctests ran in 0.73s; merged doctests compilation took 0.72s
	finished in 1.493 seconds
Build completed successfully in 0:00:01
```

</details>
tidy: Don't bypass stderr output capture in unit tests

In unit tests, writes to stderr that don't use `eprint!` or `eprintln!` will not be captured, and instead interfere with test harness output, making it unreadable.

<details>
<summary><b>Detailed before/after</b></summary>

## Before
```text
$ x test tidyselftest --no-doc
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
   Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
    Finished `release` profile [optimized + debuginfo] target(s) in 0.23s
     Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)

running 20 tests
tidy [alphabetical-test]: bad:3 found `tidy-alphabetical-start` expecting `tidy-alphabetical-end`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad: reached end of file expecting `tidy-alphabetical-end`tidy [alphabetical-test]: bad:4: line not in alphabetical order
tidy [alphabetical-test]: bad:5 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test].: tidy [alphabetical-test...bad:4: line not in alphabetical order..]: tidy [alphabetical-test]: ..
bad:7: line not in alphabetical order
tidy [tidy [bad:2 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
alphabetical-testtidy [tidy [alphabetical-test]: bad:4: line not in alphabetical order

.tidy [alphabetical-test]..]alphabetical-testtidy []: bad:4: line not in alphabetical orderalphabetical-testalphabetical-test]: tidy [FAILalphabetical-test
]: FAIL
]: FAIL
: FAIL
: bad:4: line not in alphabetical order

tidy [alphabetical-test]: FAIL
tidy [.alphabetical-test]: FAIL
.tidy [alphabetical-test]: FAIL
..tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
.....

test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.01ms

     Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 26.88µs

	finished in 0.255 seconds
Build completed successfully in 0:00:00
```

## After
```text
$ x test tidyselftest --no-doc
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
   Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
    Finished `release` profile [optimized + debuginfo] target(s) in 1.74s
     Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)

running 20 tests
....................

test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.35ms

     Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 27.17µs

	finished in 1.764 seconds
Build completed successfully in 0:00:02
```

</details>
miri subtree update

Subtree update of `miri` to 7d5ae36.

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

r? ``@ghost``
Fix typo in unstable-book link

This prevented the links from being rendered. Sorry for not noticing this before my changes were merged yesterday.

Introduced in rust-lang/rust#147935
cc ``@petrochenkov``
Add myself(chenyukang) to the review rotation

hope I have more time to catch up 💙
Rollup of 10 pull requests

Successful merges:

 - rust-lang/rust#148683 (Remove `#[const_trait]`)
 - rust-lang/rust#148687 (std: use a non-poisoning `RwLock` for the panic hook)
 - rust-lang/rust#148709 (fix: disable self-contained linker when bootstrap-override-lld is set)
 - rust-lang/rust#148716 (mgca: Finish implementation of `#[type_const]`)
 - rust-lang/rust#148722 (Add Crystal Durham to .mailmap)
 - rust-lang/rust#148723 (bootstrap: Render doctest timing reports as text, not JSON)
 - rust-lang/rust#148724 (tidy: Don't bypass stderr output capture in unit tests)
 - rust-lang/rust#148734 (miri subtree update)
 - rust-lang/rust#148736 (Fix typo in unstable-book link)
 - rust-lang/rust#148744 (Add myself(chenyukang) to the review rotation)

r? `@ghost`
`@rustbot` modify labels: rollup
…ieyouxu

Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2

Implement the [MCP 932](rust-lang/compiler-team#932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.

Closes rust-lang/rust#148353.

Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup

r? jieyouxu
cc `@davidtwco` `@Noratrieb`
This updates the rust-version file to 8401398e1f14a24670ee1a3203713dc2f0f8b3a8.
Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8
Filtered ref: 9c097c0
Upstream diff: rust-lang/rust@ceb7df7...8401398

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

rustbot commented Nov 10, 2025

Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two.
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

@rustbot rustbot added the S-waiting-on-review Status: Waiting for a review to complete label Nov 10, 2025
@RalfJung RalfJung enabled auto-merge November 10, 2025 07:19
@RalfJung RalfJung added this pull request to the merge queue Nov 10, 2025
Merged via the queue into master with commit 49ef72e Nov 10, 2025
13 checks passed
@RalfJung RalfJung deleted the rustup-2025-11-10 branch November 10, 2025 08:14
@rustbot rustbot removed the S-waiting-on-review Status: Waiting for a review to complete label Nov 10, 2025
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.

8 participants