Rollup of 8 pull requests#159516
Merged
Merged
Conversation
The `scoped_two_small_structs` test expects `sub sp, sp, rust-lang#48` on aarch64, which assumes the frame pointer (x29) is saved. Custom targets that don't set `frame-pointer: non-leaf` (e.g., OpenEmbedded/Yocto's `aarch64-poky-linux-gnu`) omit x29, producing `sub sp, sp, rust-lang#32` instead. Add `-Cforce-frame-pointers=yes` to the aarch64 revision so the test produces consistent codegen regardless of the target's default frame pointer policy. Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
A failed open of \\.\NUL for Stdio::Null surfaced as a bare OS error (usually NotFound), which reads as if the spawned program is missing. Wrap it with the operation and stream name, preserving the ErrorKind.
A trait bound `T: Fn() -> T` is non-sensical code, point that out:
```
error[E0271]: expected `{closure@trait-bound-expects-closure-returns-itself.rs:8:25}` to return `{closure@trait-bound-expects-closure-returns-itself.rs:8:25}`, but it returns `{integer}`
--> $DIR/trait-bound-expects-closure-returns-itself.rs:8:28
|
LL | closure_ret_closure(|| 4);
| -- ^ expected closure, found integer
| |
| the expected closure
|
note: a bound in `closure_ret_closure` requires that a closure return itself, which is not possible
--> $DIR/trait-bound-expects-closure-returns-itself.rs:1:39
|
LL | fn closure_ret_closure<T: FnOnce() -> T>(f: T) -> T {
| ^ this requires the closure to return itself
...
LL | closure_ret_closure(|| 4);
| ---- this closure would have to return itself
= note: expected closure `{closure@$DIR/trait-bound-expects-closure-returns-itself.rs:8:25: 8:27}`
found type `{integer}`
```
In the early days of Unicode, many systems adopted it by storing in-memory strings in (roughly) `Vec<u16>`, encoded as UCS-2 / UTF-16 / WTF-16. The “natural” way to index such strings or measure their length is counting UTF-16 code units. In some cases, such lengths or offsets found their way in protocols or APIs, such that even a Rust implementation that uses `&str` internally needs to count 16-bit code units for compatibility. For example this comes up in Servo’s implementation of some DOM APIs. One way to convert from an `&str` index (counted 8-bit code units) is: ```rust let index_16bit = string[..i].encode_utf16().count(); ``` Before this PR, the default `Iterator::count` relies on `Iterator::next` which decodes UTF-8 and encodes to UTF-16, doing more work than needed. Instead, this PR matches on bit patterns in the underlying UTF-8 string. For comparison, `str::Chars` already has a sophisticated impl for `Iterator::count` in `library/core/src/str/count.rs`.
Furthermore, populate `tests/run-make/rustdoc/doctest/` with doctest run-make tests and `tests/run-make/rustdoc/scrape-example/` with scrape example run-make tests.
…ext, r=Darksonn Windows: add context when opening NUL for child stdio fails Opening `\\.\NUL` for `Stdio::Null` can fail in some environments, and `Command::spawn`/`output()` passes the raw OS error through. In the reported case that was `NotFound`, which looks exactly like the program itself being missing. Add context saying what failed to open and for which stream: ``` failed to open NUL device for child stdin: The system cannot find the file specified. (os error 2) ``` The `ErrorKind` is kept. `raw_os_error()` on this path becomes `None` since the payload is now a message string. I don't see a way to make opening NUL fail in CI, so no test; verified by hand in a local build by pointing the open at a bogus device name and checking the error out of `Command::output()`. Fixes rust-lang#157049
…oboet Add explicit `Iterator::count` impl for `str::EncodeUtf16` In the early days of Unicode, many systems adopted it by storing in-memory strings in (roughly) `Vec<u16>`, encoded as UCS-2 / UTF-16 / WTF-16. The “natural” way to index such strings or measure their length is counting UTF-16 code units. In some cases, such lengths or offsets found their way in protocols or APIs, such that even a Rust implementation that uses `&str` internally needs to count 16-bit code units for compatibility. For example this comes up in Servo’s implementation of some DOM APIs. One way to convert from an `&str` index (counted 8-bit code units) is: ```rust let index_16bit = string[..i].encode_utf16().count(); ``` Before this PR, the default `Iterator::count` relies on `Iterator::next` which decodes UTF-8 and encodes to UTF-16, doing more work than needed. Instead, this PR matches on bit patterns in the underlying UTF-8 string. For comparison, `str::Chars` already has a sophisticated impl for `Iterator::count` in `library/core/src/str/count.rs`.
…c, r=notriddle Move rustdoc run-make tests into new `tests/run-make/rustdoc/` Furthermore, populate `tests/run-make/rustdoc/doctest/` with doctest run-make tests and `tests/run-make/rustdoc/scrape-example/` with scrape-example run-make tests. For context we currently have 11 doctest run-make tests + 8 scrape-example run-make tests + 24 other rustdoc run-make tests = 43 rustdoc run-make tests in total. **Motivation**: Sorta obvious but 1. I want to be able to just call e.g., `./x t tests/run-make/rustdoc/doctest tests/rustdoc-ui/doctest` when working on doctest internals to quickly see if anything broke instead of having to execute all run-make tests "every time I make a small change" 2. having them in one official place makes it a lot easier to spot which areas might need more coverage, to take inspiration from existing rustdoc run-make tests, to find existing test files that one can extend instead of creating a whole new run-make test, etc. r? rustdoc
…ing, r=clarfonthey Move `std::io::read_to_string` to `alloc::io` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Split From: rust-lang#156527 ~~Blocked On: rust-lang#158544 ## Description Moves `std::io::read_to_string` to `alloc::io`. This is a trivial move. Blocked on rust-lang#158544. --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see rust-lang#154046 (comment) for a review order and broader context for this PR.
…arch64-stack-check, r=mati865 tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test The `scoped_two_small_structs` test expects `sub sp, sp, rust-lang#48` on aarch64, which assumes the frame pointer (x29) is saved. Custom targets that don't set `frame-pointer: non-leaf` (e.g., OpenEmbedded/Yocto's `aarch64-poky-linux-gnu`) omit x29, producing `sub sp, sp, rust-lang#32` instead. Add `-Cforce-frame-pointers=yes` to the aarch64 revision so the test produces consistent codegen regardless of the target's default frame pointer policy.
Detect when trait bound requires closure to return itself
A trait bound `T: Fn() -> T` is non-sensical code, point that out:
```
error[E0271]: expected `{closure@trait-bound-expects-closure-returns-itself.rs:8:25}` to return `{closure@trait-bound-expects-closure-returns-itself.rs:8:25}`, but it returns `{integer}`
--> $DIR/trait-bound-expects-closure-returns-itself.rs:8:28
|
LL | closure_ret_closure(|| 4);
| -- ^ expected closure, found integer
| |
| the expected closure
|
note: a bound in `closure_ret_closure` requires that a closure return itself, which is not possible
--> $DIR/trait-bound-expects-closure-returns-itself.rs:1:39
|
LL | fn closure_ret_closure<T: FnOnce() -> T>(f: T) -> T {
| ^ this requires the closure to return itself
...
LL | closure_ret_closure(|| 4);
| ---- this closure would have to return itself
= note: expected closure `{closure@$DIR/trait-bound-expects-closure-returns-itself.rs:8:25: 8:27}`
found type `{integer}`
```
This was highlighted in rust-lang#80638. We'd since improved the output enough to close the ticket, but I wanted to ensure we had something even clearer.
Fix string indexing in diagnostic format strings Fixes rust-lang#159252 This also affects beta.
…youxu Move compiletest CLI parsing to `cli.rs` Separated out of rust-lang#159451.
rustbot
added
A-compiletest
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 18, 2026
Rollup of 8 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-*
This comment has been minimized.
This comment has been minimized.
Contributor
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Jul 18, 2026
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 8a3308ed50 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 8a3308e (parent) -> eff8269 (this PR) Test differencesShow 306 test diffsStage 1
Stage 2
(and 164 additional test diffs) Additionally, 42 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard eff8269f797067c30555e77f160ec84c0ed15cd9 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (eff8269): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.4%, secondary 2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 485.656s -> 489.126s (0.71%) |
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
Iterator::countimpl forstr::EncodeUtf16#159467 (Add explicitIterator::countimpl forstr::EncodeUtf16)tests/run-make/rustdoc/#157860 (Move rustdoc run-make tests into newtests/run-make/rustdoc/)std::io::read_to_stringtoalloc::io#158545 (Movestd::io::read_to_stringtoalloc::io)cli.rs#159500 (Move compiletest CLI parsing tocli.rs)r? @ghost
Create a similar rollup