Skip to content

Rollup of 14 pull requests #141940

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 30 commits into from

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Jun 3, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

lukaslueg and others added 30 commits May 28, 2025 18:31
…ndows

This obviously doesn't work when cross-compiling from Linux.

Split out from: rust-lang#140772
These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition
This ensures that these tests can be run on editions other than 2015
This disables the f64 minimum/maximum tests for the
arm-unknown-linux-gnueabihf job. The next release will be supporting
cross-compiled doctests, and these tests fail on that platform.

It looks like this was just fixed via
llvm/llvm-project#142170, but I assume that will
not trickle down to our copy of llvm in the next couple of weeks.
Assuming that does get fixed when llvm is updated, then these can be
removed.

cc rust-lang#141087
…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()`
…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
…-compiling, r=cuviper

rustc_llvm: add Windows system libs only when cross-compiling from Wi…

…ndows

This obviously doesn't work when cross-compiling from Linux.

Split out from: rust-lang#140772

Fixes the issue described at [#general > Problems while trying to cross compile rustc for windows](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/Problems.20while.20trying.20to.20cross.20compile.20rustc.20for.20windows/with/520508561)
Fixed a typo in `ManuallyDrop`'s doc

I noticed a typo in `ManuallyDrop`'s documentation (someone wrote "iff" instead of "if"). I fixed it in this PR.
…es, r=compiler-errors

Add missing 2015 edition directives

These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition
…rochenkov

Add missing `dyn` keywords to tests that do not test for them

This ensures that these tests can be run on editions other than 2015
Fix borrowck mentioning a name from an external macro we (deliberately) don't save

Most of the info is already in the title 🤷

Closes rust-lang#141764
remove `f16: From<u16>`

it's not a lossless conversation

r? `@tgross35`
…eVoid

[rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id

This allows consumers to create collections that required an ordering relationship for their keys—e.g. a `BTreeMap`.
Disable f64 minimum/maximum tests for arm 32

This disables the f64 minimum/maximum tests for the arm-unknown-linux-gnueabihf job. The next release will be supporting cross-compiled doctests, and these tests fail on that platform.

It looks like this was just fixed via llvm/llvm-project#142170, but I assume that will not trickle down to our copy of llvm in the next couple of weeks. Assuming that does get fixed when llvm is updated, then these can be removed.

cc rust-lang#141087
Update books

## rust-lang/book

4 commits in 230c68bc1e08f5f3228384a28cc228c81dfbd10d..634724ea85ebb08a542970bf8871ac8b0f77fd15
2025-05-29 13:16:14 UTC to 2025-05-22 21:35:03 UTC

- Chapter 10 from tech review (rust-lang/book#4379)
- Chapter 9 from tech review (rust-lang/book#4377)
- Chapter 8 from tech review (rust-lang/book#4378)
- Chapter 7 from tech review (rust-lang/book#4374)

## rust-embedded/book

3 commits in 0b8219ac23a3e09464e4e0166c768cf1c4bba0d5..10fa1e084365f23f24ad0000df541923385b73b6
2025-05-27 18:37:30 UTC to 2025-05-27 18:26:36 UTC

- portability: add reference to embedded-hal docs (rust-embedded/book#391)
- remove the unused and deprecated `multilingual` field from `book.toml` (rust-embedded/book#388)
- Ci upgrade 20250522 (rust-embedded/book#393)

## rust-lang/nomicon

4 commits in c76a20f0d987145dcedf05c5c073ce8d91f2e82a..8b61acfaea822e9ac926190bc8f15791c33336e8
2025-05-26 10:16:09 UTC to 2025-05-23 15:03:00 UTC

- Use inline const expression in unchecked-uninit.md (rust-lang/nomicon#492)
- Fix code sample output in unchecked-uninit.md (rust-lang/nomicon#491)
- Use consistent type parameters in subtyping.md (rust-lang/nomicon#493)
- Fix typo in atomics.md (rust-lang/nomicon#494)

## rust-lang/reference

1 commits in 118fd1f1f0854f50e3ae1fe4b64862aad23009ca..8e0f593a30f3b56ddb0908fb7ab9249974e08738
2025-05-31 20:12:39 UTC to 2025-05-31 20:12:39 UTC

- Minor fixes to `$crate` behavior (rust-lang/reference#1816)

## rust-lang/rust-by-example

4 commits in c9d151f9147c4808c77f0375ba3fa5d54443cb9e..21f4e32b8b40d36453fae16ec07ad4b857c445b6
2025-05-29 12:45:08 UTC to 2025-05-29 12:44:23 UTC

- Update book.toml rename `author` field to `authors` (rust-lang/rust-by-example#1917)
- Add example to comment.md to teach how to toggle a whole code block using block comments (rust-lang/rust-by-example#1919)
- The example is not meant to be compiled with out passing arguments. (rust-lang/rust-by-example#1930)
- added a shorthand for the #[should_panic(expected = "msg") (rust-lang/rust-by-example#1931)
…kingjubilee

Remove bootstrap cfgs from library/

These `cfg(bootstrap)` are always false now that rust-lang#119899 has landed, and likewise `cfg(not(bootstrap))` is always true. Therefore, we don't need to wait for the usual stage0 bump to clean these up.
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rustdoc-json Area: Rustdoc JSON backend 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 3, 2025
@workingjubilee workingjubilee deleted the rollup-aqmcppl branch June 3, 2025 01:08
@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
This PR updated 'src/doc/reference', verifying if status is 'test-pass'...

We detected that this PR updated 'reference', but its tests failed.

If you do intend to update 'reference', please check the error messages above and
commit another update.

If you do NOT intend to update 'reference', please ensure you did not accidentally
change the submodule at 'src/doc/reference'. You may ask your reviewer for the
proper steps.
Build completed unsuccessfully in 0:00:00
  local time: Tue Jun  3 01:32:49 UTC 2025
  network time: Tue, 03 Jun 2025 01:32:49 GMT
##[error]Process completed with exit code 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rustdoc-json Area: Rustdoc JSON backend 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: unexpected sort of node in fn_sig(): ImplItem(ImplItem