Skip to content

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.
Co-authored-by: Travis Cross <tc@traviscross.com>
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.
@rustbot rustbot added 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
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 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
@Kobzol
Copy link
Member

Kobzol commented May 20, 2025

The binary size and the biggest icount regressions come from #140628.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label May 20, 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. 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-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.