-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rollup of 6 pull requests #141879
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 6 pull requests #141879
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
`equialent` => `equivalent`
…ss35 Clarify &mut-methods' docs on sync::OnceLock Three small changes to the docs of `sync::OnceLock`: * The docs for `OnceLock::take()` used to [say](https://doc.rust-lang.org/std/sync/struct.OnceLock.html#method.take) "**Safety** is guaranteed by requiring a mutable reference." (emphasis mine). While technically correct, imho its not necessary to even mention safety - as opposed to unsafety - here: Safety never comes up wrt `OnceLock`, as there is (currently) no way to interact with a `OnceLock` in an unsafe way; there are no unsafe methods on `OnceLock`, so there is "safety" guarantee required anywhere. What we simply meant to say is "**Synchronization** is guaranteed...". * I've add that phrase to the other methods of `OnceLock` which take a `&mut self`, to highlight the fact that having a `&mut OnceLock` guarantees that synchronization with other threads is not required. This is the same as with [`Mutex::get_mut()`](https://doc.rust-lang.org/std/sync/struct.Mutex.html#method.get_mut), [`Cell::get_mut()`](https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut), and others. * In that spirit, the half-sentence "or being initialized" was removed from `get_mut()`, as there is no way that the `OnceLock` is being initialized while we are holding `&mut` to it. Probably a copy&paste from `.get()`
…nikic x86 (32/64): go back to passing SIMD vectors by-ptr Fixes rust-lang#139029 by partially reverting rust-lang#135408 and going back to passing SIMD vectors by-ptr on x86. Sadly, by-val confuses the LLVM inliner so much that it's not worth it... Also fixes rust-lang#141848 by no longer actually using vector registers with the "Rust" ABI. r? `@tgross35` Cc `@nikic` try-job: `test-various*` try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl try-job: x86_64-msvc-1
…ted-type-instead-of-drop-fn-fix, r=oli-obk Async drop - type instead of async drop fn, fixes rust-lang#140484 Fixes: rust-lang#140484 Fixes: rust-lang#140500 Fixes ICE, when type is provided in AsyncDrop trait instead of `async fn drop()`. Fixes ICE, when async drop fn has wrong signature.
…y-speed, r=nnethercote C-variadic functions must be unsafe tracking issue: rust-lang#44930 A function that uses `...` is always unsafe to call, because it is UB to provide the wrong number of arguments, or arguments of an unexpected type. Hence, an `unsafe extern "C" { /* ... */ }` block should not be able to declare a `safe fn` that uses `...`. cc `@joshtriplett` `@workingjubilee` I'm not really sure who'd be a good reviewer for the actual parser code. `@rustbot` label: +F-c_variadic
…Void Fix typo in `StructuralPartialEq` docs `equialent` => `equivalent`
add f16_epsilon and f128_epsilon diagnostic items cc rust-lang#116909 r? `@tgross35`
@bors r+ rollup=never p=1 |
@bors p=5 |
bors
added a commit
that referenced
this pull request
Jun 2, 2025
Rollup of 6 pull requests Successful merges: - #140715 (Clarify &mut-methods' docs on sync::OnceLock) - #141309 (x86 (32/64): go back to passing SIMD vectors by-ptr) - #141677 (Async drop - type instead of async drop fn, fixes #140484) - #141733 (C-variadic functions must be unsafe) - #141858 (Fix typo in `StructuralPartialEq` docs) - #141874 (add f16_epsilon and f128_epsilon diagnostic items) 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
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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:
unexpected sort of node in fn_sig(): ImplItem(ImplItem
#140484)StructuralPartialEq
docs #141858 (Fix typo inStructuralPartialEq
docs)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup