Skip to content

Rollup of 9 pull requests - #161706

Merged
rust-bors[bot] merged 28 commits into
rust-lang:mainfrom
GuillaumeGomez:rollup-UfytneT
Aug 25, 2026
Merged

Rollup of 9 pull requests#161706
rust-bors[bot] merged 28 commits into
rust-lang:mainfrom
GuillaumeGomez:rollup-UfytneT

Conversation

@GuillaumeGomez

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost

Create a similar rollup

durin42 and others added 28 commits August 14, 2026 10:53
LLVM 24 stopped using llvm::Any here to avoid heap allocations in
PassInstrumentation.
Before, LargeDataThreshold was only set via `LLVMRustCreateTargetMachine`.
When LTO is enabled, this information is required to be passed into the
generated LLVM module IR files since the LTO linker spins up its own
TargetMachine and otherwise has no knowledge of the LargeDataThreshold.

Currently, `-Z large-data-threshold` has no affect at all when compiling
with LTO.
This commit makes sure that if `-Z large-data-threshold` is passed and
not 0, it is preserved and stored into the generated LLVM IR.
The essential problem is that, with this table:

```text
one |
----|
  a | b | c
  a | b |
  a | b
  a |
```

And this logic:

```rust
let too_many_pipes = divider_count > expected_cells + 1;
```

`expected_cells + 1` winds up as 2, so you get this warning:

```text
error: unused content after last table cell
  --> $DIR/invalid_markdown_table.rs:81:14
   |
LL |     //!   a | b | c
   |              ^^^^^^ this content is discarded

error: unused content after last table cell
  --> $DIR/invalid_markdown_table.rs:83:14
   |
LL |     //!   a | b |
   |              ^^^^ this content is discarded

error: unused content after last table cell
  --> $DIR/invalid_markdown_table.rs:85:14
   |
LL |     //!   a | b
   |              ^^ this content is discarded
```

We really want our warning to give the suggest-escaping flow, like this:

```text
error: table row has too many columns
  --> $DIR/invalid_markdown_table.rs:81:13
   |
LL |     //!   a | b | c
   |             ^ any content after this column divider is discarded
   |
   = help: to escape `|` characters in tables, add a `\` before them like `\|`

error: table row has too many columns
  --> $DIR/invalid_markdown_table.rs:83:13
   |
LL |     //!   a | b |
   |             ^ any content after this column divider is discarded
   |
   = help: to escape `|` characters in tables, add a `\` before them like `\|`

error: unused content after last table cell
  --> $DIR/invalid_markdown_table.rs:85:14
   |
LL |     //!   a | b
   |              ^^ this content is discarded
```

By only scanning the text between the end of the last cell and the row,
instead of doing the entire row, we don't have to re-implement as much
of pulldown-cmark's logic.
Previously, the code unwrapped large_data_threshold with a default of
0 and sets it in the LLVM module if it is != 0.
Instead, we should simply check if large_data_threshold has a value.
bootstrap: don't LTO C dependencies on aarch64

Since rust-lang#161535 apparently may take a while, let's land something to un-break Miri: we know that on aarch64-linux, shipping pure-LTO object files is a bad idea as we can't assume the user has an LTO-capable linker.

r? @Kobzol
Cc @weihanglo
…, r=GuillaumeGomez

rustdoc: fix issue preventing "read more" links from generating.

fixes rust-lang#161300
…nagisa

Pass LargeDataThreshold to LLVM module IR

Before, LargeDataThreshold was only set via `LLVMRustCreateTargetMachine`. When LTO is enabled, this information is required to be passed into the generated LLVM module IR files since the LTO linker spins up its own TargetMachine and otherwise has no knowledge of the LargeDataThreshold.

Currently, `-Z large-data-threshold` has no affect at all when compiling with LTO.
This commit makes sure that if `-Z large-data-threshold` is passed and not 0, it is preserved and stored into the generated LLVM IR.
…=GuillaumeGomez

rustdoc: Nuke `--passes=list` and defossilize the passes infrastructure

`--passes` and `--no-defaults` were deprecated and made noops years ago except that `--passes list` still prints all passes in a human-readable format as if users could still somehow make use of that information. Removing this useless functionality allows for some small simplifications (and longer term, it would enable us to further rewrite the way we represent internal passes w/o having to worry about it possibly affecting the CLI).

Given that the output of `--passes list` is *clearly* meant for human consumption only (I mean, just look at it), I hold the opinion that this removal doesn't need an FCP. And even if there were scripts somewhere out there that try to parse this output I think it would be okay to break them.
…t-links-url, r=GuillaumeGomez

Check `redundant_explicit_links` against generated URLs

Fixes rust-lang#155458.

`rustdoc::redundant_explicit_links` checked explicit link destinations by resolving both the label and the destination as intra-doc paths. That misses links written as local rustdoc page URLs, such as `struct.B.html`, because those URLs do not appear in `doc_link_resolutions`.

This PR keeps the existing path-resolution check and falls back to comparing the explicit destination with the local href that rustdoc would generate for the resolved label.
…able_cell, r=Urgau,notriddle,camelid

Add new `invalid_markdown_table` rustdoc lint

Fixes rust-lang#159186.

r? @Urgau
…=cuviper

PassWrapper: handle LLVM 24 change in function types

LLVM 24 stopped using llvm::Any here [to avoid heap allocations](llvm/llvm-project@fa23198) in PassInstrumentation.

@rustbot label: +llvm-main
…k-fix, r=cuviper

Check for missing rustfmt in the stdarch intrinsic test step sooner

Found [here](rust-lang#161422 (comment)).

r? cuviper
…re, r=ChrisDenton

Don't treat slashes as path seps after drive letters in verbatim paths

Treat slashes as just a regular character in `\\?\C:/path\somewhere`. This mirrors how slashes are treated afterwards, e.g. in `\\?\C:\path/somewhere`, which has a component `path/somewhere`, rather than `path`, `somewhere`.

Likewise, drive letters followed by `/` do not denote a `VerbatimDisk`, but an arbitrary `Verbatim` path: The prefix of `\\?\C:/path\somewhere` is `\\?\C:/path`.

Fixes rust-lang#161651
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Aug 24, 2026
@rustbot rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Aug 24, 2026
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Aug 24, 2026
@GuillaumeGomez

Copy link
Copy Markdown
Member Author

@bors r+ p=5

@rust-bors

rust-bors Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 21b4ef6 has been approved by GuillaumeGomez

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 24, 2026
@rust-bors

This comment has been minimized.

@rust-bors rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 25, 2026
@rust-bors

rust-bors Bot commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

☀️ Test successful - CI
Approved by: GuillaumeGomez
Duration: 3h 6m 22s
Pushing 9bb55c8 to main...

@rust-bors
rust-bors Bot merged commit 9bb55c8 into rust-lang:main Aug 25, 2026
14 checks passed
@rustbot rustbot added this to the 1.100.0 milestone Aug 25, 2026
@github-actions

Copy link
Copy Markdown
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 e776960 (parent) -> 9bb55c8 (this PR)

Test differences

Show 15 test diffs

Stage 1

  • [codegen] tests/codegen-llvm/large_data_threshold.rs#DEFAULT: [missing] -> pass (J2)
  • [codegen] tests/codegen-llvm/large_data_threshold.rs#EXPLICIT: [missing] -> pass (J2)
  • [rustdoc-html] tests/rustdoc-html/trait-read-more-161300.rs: [missing] -> pass (J2)
  • [ui] tests/rustdoc-ui/lints/invalid_markdown_table.rs: [missing] -> pass (J2)
  • [codegen] tests/codegen-llvm/large_data_threshold.rs#DEFAULT: [missing] -> ignore (only executed when the architecture is x86_64) (J3)
  • [codegen] tests/codegen-llvm/large_data_threshold.rs#EXPLICIT: [missing] -> ignore (only executed when the architecture is x86_64) (J3)

Stage 2

  • [codegen] tests/codegen-llvm/large_data_threshold.rs#DEFAULT: [missing] -> pass (J0)
  • [codegen] tests/codegen-llvm/large_data_threshold.rs#EXPLICIT: [missing] -> pass (J0)
  • [codegen] tests/codegen-llvm/large_data_threshold.rs#DEFAULT: [missing] -> ignore (only executed when the architecture is x86_64) (J1)
  • [codegen] tests/codegen-llvm/large_data_threshold.rs#EXPLICIT: [missing] -> ignore (only executed when the architecture is x86_64) (J1)
  • [rustdoc-html] tests/rustdoc-html/trait-read-more-161300.rs: [missing] -> pass (J4)
  • [ui] tests/rustdoc-ui/lints/invalid_markdown_table.rs: [missing] -> pass (J4)
  • sys::path::windows::tests::test_verbatim_disk_issue_161651: [missing] -> pass (J5)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 9bb55c8c865411b7d9dea6ff743e583d510d89f5 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-gnu-llvm-21-2: 1h -> 1h 31m (+51.8%)
  2. dist-i686-mingw: 1h 49m -> 2h 39m (+46.2%)
  3. dist-i686-linux: 1h 46m -> 1h 10m (-33.9%)
  4. i686-gnu-1: 1h 36m -> 2h 7m (+32.7%)
  5. x86_64-gnu-llvm-21-1: 53m 52s -> 38m 45s (-28.1%)
  6. test-various: 2h 3m -> 1h 31m (-26.2%)
  7. x86_64-gnu-next-trait-solver-polonius: 43m 2s -> 53m 25s (+24.1%)
  8. x86_64-msvc-1: 2h 42m -> 2h 3m (-23.7%)
  9. dist-x86_64-msvc-alt: 2h 51m -> 2h 10m (-23.6%)
  10. x86_64-gnu-llvm-21: 40m 1s -> 49m 21s (+23.3%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (9bb55c8): comparison URL.

Overall result: ❌ regressions - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.6%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.5% [0.5%, 0.6%] 2

Max RSS (memory usage)

Results (primary 6.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
6.7% [2.7%, 10.6%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 6.7% [2.7%, 10.6%] 2

Cycles

Results (primary -2.7%, secondary 0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.2% [3.2%, 3.2%] 1
Improvements ✅
(primary)
-2.7% [-2.7%, -2.7%] 1
Improvements ✅
(secondary)
-2.7% [-2.7%, -2.7%] 1
All ❌✅ (primary) -2.7% [-2.7%, -2.7%] 1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 471.419s -> 476.471s (1.07%)
Artifact size: 400.34 MiB -> 400.96 MiB (0.16%)

@rustbot rustbot added the perf-regression Performance regression. label Aug 25, 2026
@rust-bors

rust-bors Bot commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#161689 bootstrap: don't LTO C dependencies on aarch64 89d9a83de62eb9f0a01a1b1a5b83e3e246f26285
(link)
#161553 rustdoc: fix issue preventing "read more" links from genera… 589a9c5d23f118f38e0599549caf701590986bd0
(link)
#161670 Pass LargeDataThreshold to LLVM module IR 9e74e414d5f8a446e6dcb42fd968116ec87c0a74
(link)
#146529 rustdoc: Nuke --passes=list and defossilize the passes in… 51502e86ac48af8f9f53795845b470259817622a
(link)
#156009 Check redundant_explicit_links against generated URLs 823287b65dd11740d03568285145ba144f950b23
(link)
#159583 Add new invalid_markdown_table rustdoc lint ff4bc60fc43dcc2cbeca3d74f550a920e95ec641
(link)
#161098 PassWrapper: handle LLVM 24 change in function types db040b543c43d704354ffd1c196ef9e78dab3fa2
(link)
#161641 Check for missing rustfmt in the stdarch intrinsic test ste… 33e5e74229f0bc41bd0addbd5a5b9f9e88bc9779
(link)
#161661 Don't treat slashes as path seps after drive letters in ver… 745a7e5d682ad5f015fb4e77f1af4b5b9882706c
(link)

parent commit: e7769602ac

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. rollup A PR which is a rollup T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.