Skip to content

Rollup of 8 pull requests #141567

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 26 commits into from
May 26, 2025
Merged

Rollup of 8 pull requests #141567

merged 26 commits into from
May 26, 2025

Conversation

jhpratt
Copy link
Member

@jhpratt jhpratt commented May 26, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

SimonSapin and others added 26 commits May 12, 2025 18:43
There only needs to be one `Fn` per symbol, not multiple.
Some are too long (> 100 chars), some are too short, some are missing
full stops, some are missing upper-case letters at the start of
sentences.
In several files they are entirely unnecessary, with the relevant names
already imported. And in a few I have added the necessary `use` item.
…=workingjubilee

Implement `normalize_lexically`

Implements rust-lang#134694

This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.
…ups, r=jdonszelmann

Simplify `attribute_groups`

It's more complicated than it needs to be.

r? ``@jdonszelmann``
…der, r=lolbinarycat

[rustdoc] Unify type aliases rendering with other ADT

Fixes rust-lang#140739.

Better reviewed one commit at a time.

Just one thing I'm wondering: should we also render non-`repr` attributes? If so, I wonder if we shouldn't simply change `clean::TypeAlias` to contain the other ADT directly (`Struct`, `Enum` and `Union`) and remove the `TypeAlias::generics` field.

Can be done in a follow-up too.

cc ``@camelid``
r? ``@notriddle``
…kingjubilee

Clarify WTF-8 safety docs

This PR is a follow-up to PR rust-lang#140159, which clarifies ~~two things~~:
- the WTF-8 safety comment [was confusing](rust-lang#140159 (comment)), either surrogate condition is actually sufficient for safety, both are not required
- ~~the private `os_str::Slice` type name is easily confused with `std::slice`~~

~~Happy to bikeshed the `OsSlice` name, other alternatives are `OsStrSlice` and `StrSlice`. Now it's got a distinct name from `std::slice`, it's easy to search and replace.~~

cc ``@thaliaarchi`` ``@workingjubilee``
…tion, r=dtolnay

Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace
Attempt to improve the `std::fs::create_dir_all` docs related to atomicity

The original paragraph was added in rust-lang#124520. It doesn't match the actual code logic. It says "function returns an error" if "the parent components" _(which also implies directories)_ "have been created already". The code is as follows:

https://github.com/rust-lang/rust/blob/e88e85463468ce5d5ce468414eb69e3b15fa8d42/library/std/src/fs.rs#L3146
https://github.com/rust-lang/rust/blob/e88e85463468ce5d5ce468414eb69e3b15fa8d42/library/std/src/fs.rs#L3160

These lines suppress all errors if any path component is a directory. I've updated the paragraph to mirror this.
…ld, r=Kobzol

ci: move PR job x86_64-gnu-tools to codebuild
…_unstable, r=compiler-errors

const-check: stop recommending the use of rustc_allow_const_fn_unstable

I have seen way too many people see the compiler suggest this attribute and then just apply it without a second thought. This is bad. So let's just stop recommending it; for the rare case where someone needs it, they'll eventually ask us and that way we can be sure that it is truly needed. The dev-guide still also explains `rustc_allow_const_fn_unstable`.

Cc ``@rust-lang/wg-const-eval``
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-rustdoc-json Area: Rustdoc JSON backend 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. labels May 26, 2025
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure 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. rollup A PR which is a rollup labels May 26, 2025
@jhpratt
Copy link
Member Author

jhpratt commented May 26, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented May 26, 2025

📌 Commit 5a8cb6f has been approved by jhpratt

It is now in the queue for this repository.

@bors bors 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 May 26, 2025
@bors
Copy link
Collaborator

bors commented May 26, 2025

⌛ Testing commit 5a8cb6f with merge 95a2212...

@bors
Copy link
Collaborator

bors commented May 26, 2025

☀️ Test successful - checks-actions
Approved by: jhpratt
Pushing 95a2212 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 26, 2025
@bors bors merged commit 95a2212 into rust-lang:master May 26, 2025
8 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 26, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#134696 Implement normalize_lexically 22068098447527f2c5f859758a5151100739932e (link)
#140539 Simplify attribute_groups 1c9d8480b5c7106911021f4e3d8c9a6fb2962bc6 (link)
#140863 [rustdoc] Unify type aliases rendering with other ADT 5c8352561cb4f25b5fc95898847dee1cebc67951 (link)
#140936 Clarify WTF-8 safety docs c2e3bda73c7bd3e0e986e80b6778f313e1086334 (link)
#140952 Specify that split_ascii_whitespace uses the same definitio… ad0c0d0945c343145459a3f35356b93abca057ec (link)
#141472 Attempt to improve the std::fs::create_dir_all docs relat… 7519fa8e52a3ea508881fd780e9cb4f17b79579e (link)
#141502 ci: move PR job x86_64-gnu-tools to codebuild 6e8736bf3f37dc82edd5d3613f63ac9a41c9f5e0 (link)
#141559 const-check: stop recommending the use of rustc_allow_const… a388bea4c6123257432624ac791de1f9c17d177b (link)

previous master: 46264e6dfd

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

Copy link

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 46264e6 (parent) -> 95a2212 (this PR)

Test differences

Show 496 test diffs

Stage 0

  • normalize_lexically: [missing] -> pass (J3)

Stage 1

  • [rustdoc] tests/rustdoc/type-alias/repr.rs: [missing] -> pass (J0)
  • normalize_lexically: [missing] -> pass (J1)

Stage 2

  • [rustdoc] tests/rustdoc/type-alias/repr.rs: [missing] -> pass (J2)

Additionally, 492 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 95a2212587f1b8500af1ac630322b0cb2e030c61 --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. aarch64-apple: 4225.7s -> 5398.1s (27.7%)
  2. x86_64-apple-2: 5459.0s -> 6631.5s (21.5%)
  3. dist-x86_64-apple: 9682.9s -> 8095.9s (-16.4%)
  4. aarch64-gnu-debug: 3985.5s -> 4634.9s (16.3%)
  5. dist-aarch64-apple: 5284.8s -> 6139.9s (16.2%)
  6. dist-apple-various: 7001.8s -> 7801.0s (11.4%)
  7. x86_64-apple-1: 7268.8s -> 7727.7s (6.3%)
  8. x86_64-msvc-ext3: 7826.5s -> 7390.1s (-5.6%)
  9. dist-x86_64-illumos: 5816.9s -> 5537.6s (-4.8%)
  10. x86_64-gnu-llvm-20-3: 6973.8s -> 7292.6s (4.6%)
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
Collaborator

Finished benchmarking commit (95a2212): comparison URL.

Overall result: ❌ regressions - please read the text below

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

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary 3.2%, secondary -3.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

Results (primary 3.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

Results (primary 1.1%, secondary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
1.1% [1.1%, 1.1%] 1
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 4
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.1% [1.1%, 1.1%] 1

Bootstrap: 776.159s -> 776.359s (0.03%)
Artifact size: 366.24 MiB -> 366.28 MiB (0.01%)

@rustbot rustbot added the perf-regression Performance regression. label May 26, 2025
@jhpratt jhpratt deleted the rollup-uuhcmci branch May 26, 2025 18:48
@lqd
Copy link
Member

lqd commented May 26, 2025

clap_derive is noisy, and has since gone back to its previous state.

This PR is the last peak
image

@rylev
Copy link
Member

rylev commented May 27, 2025

Because of the previous comment:

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-rustdoc-json Area: Rustdoc JSON backend 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. perf-regression-triaged The performance regression has been triaged. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure 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.