Skip to content

Rollup of 10 pull requests #141228

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

Closed
wants to merge 40 commits into from
Closed

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.
Use the existing Lemire (decimal -> float) and Dragon / Grisu algorithms
(float -> decimal) to add support for `f16`. This allows updating the
implementation for `Display` to the expected behavior for `Display`
(currently it prints the a hex bitwise representation), matching other
floats, and adds a `FromStr` implementation.

In order to avoid crashes when compiling with Cranelift or on targets
where f16 is not well supported, a fallback is used if
`cfg(target_has_reliable_f16)` is not true.
Extend the existing tests for `f32` and `f64` with versions that include
`f16`'s new printing and parsing implementations.

Co-authored-by: Speedy_Lex <[email protected]>
This requires a fix to the subnormal test to cap the maximum allowed
value within the maximum mantissa.
apparently it doesn't really use the asm parsing at present, so this may work?
fmease added 8 commits May 18, 2025 17:14
Cygwin support in rustc

This PR builds host rustc targeting cygwin.

- [x] rust-lang/stacker#122
- [x] nagisa/rust_libloading#173
- [x] Detegr/rust-ctrlc#131
- [x] rust-random/getrandom#654
- [x] msys2/MSYS2-packages#5350
- [x] rust-lang#140886
- [x] rust-lang#140921
- [x] rust-lang#140973

Currently supported:
* rustc
* rustdoc
* rustfmt
* clippy

Blocking:
* cargo: blocked by rust-lang/socket2#568
* rust-analyzer: needs `cargo update`, fixed upstream

```
$ rustc --version --verbose
rustc 1.88.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-pc-cygwin
release: 1.88.0-dev
LLVM version: 20.1.4
```
…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 383aef0 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 383aef0 with merge 53f7119...

bors added a commit to rust-lang-ci/rust that referenced this pull request May 18, 2025
Rollup of 10 pull requests

Successful merges:

 - rust-lang#127013 (Add `f16` formatting and parsing)
 - rust-lang#138940 (Stabilize the avx512 target features)
 - rust-lang#140154 (Cygwin support in rustc)
 - rust-lang#140490 (split `asm!` parsing and validation)
 - rust-lang#140628 (std: stop using TLS in signal handler)
 - rust-lang#140746 (name resolution for guard patterns)
 - rust-lang#140926 (Return value of coroutine_layout fn changed to Result with LayoutError)
 - rust-lang#141127 (bump windows crate for compiler,bootstrap and tools)
 - rust-lang#141214 (Miri subtree update)
 - rust-lang#141218 (gvn: avoid creating overlapping assignments)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] test_float_parse test:false 10.619
[RUSTC-TIMING] test_float_parse test:false 0.292
    Finished `release` profile [optimized] target(s) in 22.55s
##[endgroup]
[TIMING] core::build_steps::tool::ToolBuild { compiler: Compiler { stage: 2, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu, tool: "test-float-parse", path: "src/etc/test-float-parse", mode: ToolStd, source_type: InTree, extra_features: [], allow_features: "f16,cfg_target_has_reliable_f16_f128", cargo_args: [], artifact_kind: Binary } -- 22.577
[TIMING] core::build_steps::tool::TestFloatParse { host: x86_64-unknown-linux-gnu } -- 0.000
##[group]Testing test-float-parse (stage2 -> stage3, x86_64-unknown-linux-gnu)
[RUSTC-TIMING] autocfg test:false 0.513
[RUSTC-TIMING] build_script_build test:false 0.108
[RUSTC-TIMING] build_script_build test:false 0.299
---
46   |         unsafe { intrinsics::powf16(self, n) }
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ unimplemented intrinsic: `powf16`
     |
     = help: this is likely not a bug in the program; it indicates that the program performed an operation that Miri does not support
     = note: BACKTRACE on thread `num::dec2flt::f`:
     = note: inside `std::f16::<impl f16>::powf` at /checkout/library/std/src/f16.rs:46:18: 46:45
note: inside `num::dec2flt::float::test_f16_integer_decode`
    --> library/coretests/tests/num/dec2flt/float.rs:9:21
     |
9    |     assert_eq!(2f16.powf(14.0).integer_decode(), (1 << 10, 4, 1));
     |                     ^^^^^^^^^^
note: inside closure
    --> library/coretests/tests/num/dec2flt/float.rs:6:29
     |
4    | #[test]
     | ------- in this procedural macro expansion
5    | #[cfg(target_has_reliable_f16)]
6    | fn test_f16_integer_decode() {
     |                             ^
     |
    ::: /checkout/library/core/src/macros/mod.rs:1656:5
     |
1656 |     pub macro test($item:item) {
     |     -------------- in this expansion of `#[test]`
note: inside `<{closure@library/coretests/tests/num/dec2flt/float.rs:6:1: 19:2} as std::ops::FnOnce<()>>::call_once - shim`
    --> /checkout/library/core/src/ops/function.rs:250:5
     |
250  |     extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `<fn() -> std::result::Result<(), std::string::String> as std::ops::FnOnce<()>>::call_once - shim(fn() -> std::result::Result<(), std::string::String>)`
---

error: test failed, to rerun pass `-p coretests --test coretests`

Caused by:
  process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/bin/cargo-miri runner /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/miri/x86_64-unknown-linux-gnu/debug/deps/coretests-41766f620c5c8ff7 -Z unstable-options --format json` (exit status: 1)
note: test exited abnormally; to see the full output pass --nocapture to the harness.
Build completed unsuccessfully in 0:21:23
make: *** [Makefile:53: check-aux] Error 1
  local time: Sun May 18 16:37:22 UTC 2025
  network time: Sun, 18 May 2025 16:37:22 GMT
##[error]Process completed with exit code 2.
Post job cleanup.

@bors
Copy link
Collaborator

bors commented May 18, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 18, 2025
@fmease fmease closed this May 18, 2025
@fmease fmease deleted the rollup-yqpyhpz branch May 18, 2025 16:45
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 O-unix Operating system: Unix-like rollup A PR which is a rollup 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.