-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Closed
Rollup of 10 pull requests #141228
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <[email protected]>
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.
Automatic Rustup
Co-authored-by: Travis Cross <[email protected]>
apparently it doesn't really use the asm parsing at present, so this may work?
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.
Miri subtree update r? `@ghost` Fixes rust-lang/miri#4328
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
@bors r+ rollup=never p=5 |
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
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
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.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
f16
formatting and parsing #127013 (Addf16
formatting and parsing)asm!
parsing and validation #140490 (splitasm!
parsing and validation)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup