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: Ookiineko <chiisaineko@protonmail.com>
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 <alex.ciocildau@gmail.com>
This requires a fix to the subnormal test to cap the maximum allowed
value within the maximum mantissa.
Co-authored-by: Travis Cross <tc@traviscross.com>
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.