Skip to content

Rollup of 8 pull requests #141232

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 31 commits into from
May 18, 2025
Merged

Rollup of 8 pull requests #141232

merged 31 commits into from
May 18, 2025

Conversation

fmease
Copy link
Member

@fmease fmease commented May 18, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joboet and others added 30 commits May 5, 2025 15:18
TLS is not async-signal-safe, making its use in the signal handler used to detect stack overflows unsound (c.f. rust-lang#133698). POSIX however lists two thread-specific identifiers that can be obtained in a signal handler: the current `pthread_t` and the address of `errno`. Since `pthread_equal` is not AS-safe, `pthread_t` should be considered opaque, so for our purposes, `&errno` is the only option. This however works nicely: we can use the address as a key into a map that stores information for each thread. This PR uses a `BTreeMap` protected by a spin lock to hold the guard page address and thread name and thus fixes rust-lang#133698.
I'll be modifying it in future commits, so I think it's cleanest to
abstract it out. Possibly a newtype would be ideal, but for now this is
least disruptive.
This splits introduction of bindings into scope
(`apply_pattern_bindings`) apart from manipulation of the pattern's
binding map (`fresh_binding`). By delaying the latter, we can keep
bindings from appearing in-scope in guards.

Since `fresh_binding` is now specifically for manipulating a pattern's
bindings map, this commit also inlines a use of `fresh_binding` that was
only adding to the innermost rib.
apparently it doesn't really use the asm parsing at present, so this may work?
…u,traviscross

Stabilize the avx512 target features

This PR stabilizes the AVX512 target features - see [this comment](rust-lang#111137 (comment)).

Tracking Issue - rust-lang#44839

The target feature UI tests have been changed to `x87` (chosen because this is very unlikely to stablize ever, please comment if some other feature will be better)

related: rust-lang#111137
…manieu,traviscross

split `asm!` parsing and validation

This PR splits `asm!` parsing and validation into two separate steps.

The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros.
The validation then checks things like ordering of arguments or that options are not provided twice.

The motivation is rust-lang#140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`.

An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable rust-lang/style-team#152).

r? ``@ghost`` (just want to look at CI for now)

cc ``@ytmimi`` we discussed asm formatting a little while ago in rust-lang/rustfmt#6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before?

try-job: aarch64-apple
…imulacrum

std: stop using TLS in signal handler

TLS is not async-signal-safe, making its use in the signal handler used to detect stack overflows unsound (c.f. rust-lang#133698). POSIX however lists two thread-specific identifiers that can be obtained in a signal handler: the current `pthread_t` and the address of `errno`. Since `pthread_equal` is not AS-safe, `pthread_t` should be considered opaque, so for our purposes, `&errno` is the only option. This however works nicely: we can use the address as a key into a map that stores information for each thread. This PR uses a `BTreeMap` protected by a spin lock to hold the guard page address and thread name and thus fixes rust-lang#133698.
name resolution for guard patterns

This PR provides an initial implementation of name resolution for guard patterns [(RFC 3637)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md). This does not change the requirement that the bindings on either side of an or-pattern must be the same [(proposal here)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md#allowing-mismatching-bindings-when-possible); the code that handles that is separate from what this PR touches, so I'm saving it for a follow-up.

On a technical level, this separates "collecting the bindings in a pattern" (which was already done for or-patterns) from "introducing those bindings into scope". I believe the approach used here can be extended straightforwardly in the future to work with `if let` guard patterns, but I haven't tried it myself since we don't allow those yet.

Tracking issue for guard patterns: rust-lang#129967

cc ``@Nadrieril``
…ne-layout-returns-layout-error, r=oli-obk

Return value of coroutine_layout fn changed to Result with LayoutError

Continue of rust-lang#140902:
`coroutine_layout` fn is now returns `Result` with `LayoutError` to have consistent error with `layout_of_uncached`.
`async_drop_coroutine_layout` fn is now return `LayoutError::TooGeneric` in case of not-fully-specialized `async_drop_in_place<T>::{closure}` coroutine.
…rsan68,jieyouxu

bump windows crate for compiler,bootstrap and tools

This dedupes crate versions. For `x86_64-pc-windows-msvc` stage1 cuts few kb from `rustc_driver.dll`, nice.
gvn: avoid creating overlapping assignments

Quick fix rust-lang#141038, as I couldn't find a way to avoid in-place modification. I'm considering handling all `ravlue` modifications within the `visit_statement` function.

r? mir-opt
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool O-unix Operating system: Unix-like 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. rollup A PR which is a rollup labels May 18, 2025
@fmease
Copy link
Member Author

fmease commented May 18, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented May 18, 2025

📌 Commit 50b20b7 has been approved by fmease

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

bors commented May 18, 2025

⌛ Testing commit 50b20b7 with merge 4455c89...

@bors
Copy link
Collaborator

bors commented May 18, 2025

☀️ Test successful - checks-actions
Approved by: fmease
Pushing 4455c89 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 18, 2025
@bors bors merged commit 4455c89 into rust-lang:master May 18, 2025
1 check passed
@rustbot rustbot added this to the 1.89.0 milestone May 18, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#138940 Stabilize the avx512 target features 327d73668bff30a78c106fd7f5ace10f47725281 (link)
#140490 split asm! parsing and validation fde8258ecf85fc5dc1c56988a1a70aac7c86e873 (link)
#140628 std: stop using TLS in signal handler 92336870cb3a86b34b4b02e06db9dd04a099ed04 (link)
#140746 name resolution for guard patterns d39028d8cd281c73a6283b371269b5ee1fe4ef7c (link)
#140926 Return value of coroutine_layout fn changed to Result with … 0453a8fd52b84245d1dfdf28399147dc95045ac8 (link)
#141127 bump windows crate for compiler,bootstrap and tools deefe4c1e883208f3517c5b8e478177d9d454c0e (link)
#141214 Miri subtree update 70b2267c268c910e37e97842afc9b24b56752e9a (link)
#141218 gvn: avoid creating overlapping assignments cabbe64191d448fec04fcf2c8deb3e2029454fc7 (link)

previous master: b53e5c9db0

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 b53e5c9 (parent) -> 4455c89 (this PR)

Test differences

Show 20 test diffs

Stage 1

  • [mir-opt] tests/mir-opt/gvn_overlapping.rs: [missing] -> pass (J1)
  • [ui] tests/ui/pattern/rfc-3637-guard-patterns/name-resolution.rs: [missing] -> pass (J1)

Stage 2

  • [mir-opt] tests/mir-opt/gvn_overlapping.rs: [missing] -> pass (J0)
  • [ui] tests/ui/pattern/rfc-3637-guard-patterns/name-resolution.rs: [missing] -> pass (J2)

Additionally, 16 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 4455c8937007f3cc3c078375a335d86dbab391ce --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. dist-aarch64-linux: 7485.8s -> 5276.3s (-29.5%)
  2. dist-apple-various: 7783.8s -> 5946.6s (-23.6%)
  3. x86_64-apple-1: 9147.4s -> 7586.7s (-17.1%)
  4. dist-arm-linux: 5185.7s -> 4583.5s (-11.6%)
  5. dist-aarch64-apple: 5528.4s -> 5047.6s (-8.7%)
  6. x86_64-apple-2: 5289.1s -> 4891.2s (-7.5%)
  7. dist-ohos-aarch64: 4863.0s -> 4569.3s (-6.0%)
  8. dist-armhf-linux: 5372.9s -> 5058.4s (-5.9%)
  9. x86_64-msvc-ext1: 7463.6s -> 7033.4s (-5.8%)
  10. x86_64-gnu-llvm-20-2: 5902.2s -> 6240.9s (5.7%)
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 (4455c89): comparison URL.

Overall result: ❌✅ regressions and improvements - 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)
0.8% [0.4%, 1.2%] 8
Regressions ❌
(secondary)
0.9% [0.2%, 3.2%] 15
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.7% [-1.0%, -0.0%] 4
All ❌✅ (primary) 0.8% [0.4%, 1.2%] 8

Max RSS (memory usage)

Results (primary -1.5%, secondary -2.4%)

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.1% [3.1%, 3.1%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.7% [-5.8%, -1.2%] 4
Improvements ✅
(secondary)
-2.4% [-5.5%, -0.6%] 8
All ❌✅ (primary) -1.5% [-5.8%, 3.1%] 5

Cycles

Results (primary 0.6%, secondary 0.2%)

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)
0.6% [0.6%, 0.6%] 2
Regressions ❌
(secondary)
1.5% [0.5%, 3.6%] 11
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.1% [-4.6%, -0.5%] 6
All ❌✅ (primary) 0.6% [0.6%, 0.6%] 2

Binary size

Results (primary 1.4%, secondary 3.5%)

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.4% [0.2%, 3.9%] 29
Regressions ❌
(secondary)
3.5% [0.3%, 4.0%] 76
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.4% [0.2%, 3.9%] 29

Bootstrap: 776.543s -> 775.321s (-0.16%)
Artifact size: 365.45 MiB -> 365.53 MiB (0.02%)

@rustbot rustbot added the perf-regression Performance regression. label May 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool merged-by-bors This PR was explicitly merged by bors. O-unix Operating system: Unix-like perf-regression Performance regression. 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-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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.