Merge subtree update for toolchain nightly-2025-08-14 #461
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
They are subsumed by the main repo licenses.
Rename `tests/{assembly,codegen}` into `tests/{assembly,codegen}-llvm` and ignore these testsuites if configured backend doesn't match
Follow-up of rust-lang#144125.
This PR changes `compiletest` so that `asm` tests are only run if they match the current codegen backend. To better reflect it, I renamed the `tests/ui/asm` folder into `tests/ui/asm-llvm`. Like that, we can add new asm tests for other backends if we want without needing to add extra code to `compiletest`.
Next step will be to use the new code annotations added in rust-lang#144125 to ignore ui tests failing in cg_gcc until it's fixed on our side.
cc `@antoyo` `@oli-obk`
r? `@Kobzol`
- Use EFI_TCP4_GET_MODE_DATA to be able to query for ttl, nodelay, peer_addr and socket_addr. - peer_addr is needed for implementation of `accept`. Signed-off-by: Ayush Singh <[email protected]>
We now have access to native runners, so make use of them for these architectures. The existing ppc64le Docker job is kept for now.
Move `std_detect` into stdlib This PR moves the `std_detect` crate from `stdarch` to be a part of rust-lang/rust instead. The first commit actually moves the whole directory from the stdarch Josh subtree, so that git blame history is kept intact. Then I had to make a few changes to appease `tidy`. The most complex thing here is porting the tests. We can't have `std_detect` both in r-l/r and stdarch, because they could get desynchronized, so we have to perform the move more or less "atomically", which means that we also have to port all the existing `std_detect` tests from the `stdarch` repository. The stdarch repo runs the following `std_detect` tests: ### Build The `build-std-detect.sh` script (https://github.com/rust-lang/stdarch/blob/e2b6512aed87df45294ae680181eeef7a802cd95/ci/build-std-detect.sh) builds `std_detect` using the nightly compiler for several targets. This will be subsumed by normal `x build library` on our Tier 1/2 targets. However, the stdarch repository also tests the following targets: - aarch64-unknown-freebsd - armv6-unknown-freebsd - powerpc-unknown-freebsd - powerpc64-unknown-freebsd - aarch64-unknown-openbsd Which we don't build/test on our CI currently. I think we have mostly two options here: 1) Ignore these targets 2) Create a special CI job that will build stage 1 rustc and then cross-compile std (or just the `std_detect` crate?) for these targets. ### Documentation The `dox.sh` script (https://github.com/rust-lang/stdarch/blob/3fec5adcd52a815f227805d4959a25b6402c7fd5/ci/dox.sh) builds and documents `std_detect` for several targets. All of them are Tier 2/we have `dist-` jobs for them, so I think that we can just skip this and let our normal CI subsume it? ### Tests The `run.sh` script (https://github.com/rust-lang/stdarch/blob/1b201cec2cca7465602a65ed6ae60517224b15f3/ci/run.sh) runs `cargo test` on `std_detect` with a bunch of variations of feature flags. This will be subsumed by `x test library` in our CI. The only problem is that `stdarch` runs these tests for a ludicrous number of targets: ``` - tuple: i686-unknown-linux-gnu - tuple: x86_64-unknown-linux-gnu - tuple: arm-unknown-linux-gnueabihf - tuple: armv7-unknown-linux-gnueabihf - tuple: aarch64-unknown-linux-gnu - tuple: aarch64_be-unknown-linux-gnu - tuple: riscv32gc-unknown-linux-gnu - tuple: riscv64gc-unknown-linux-gnu - tuple: powerpc-unknown-linux-gnu - tuple: powerpc64-unknown-linux-gnu - tuple: powerpc64le-unknown-linux-gnu - tuple: s390x-unknown-linux-gnu - tuple: i586-unknown-linux-gnu - tuple: nvptx64-nvidia-cuda - tuple: thumbv6m-none-eabi - tuple: thumbv7m-none-eabi - tuple: thumbv7em-none-eabi - tuple: thumbv7em-none-eabihf - tuple: loongarch64-unknown-linux-gnu - tuple: wasm32-wasip1 - tuple: x86_64-apple-darwin - tuple: x86_64-apple-ios-macabi - tuple: aarch64-apple-darwin - tuple: aarch64-apple-ios-macabi - tuple: x86_64-pc-windows-msvc - tuple: i686-pc-windows-msvc - tuple: aarch64-pc-windows-msvc - tuple: x86_64-pc-windows-gnu - tuple: aarch64-unknown-linux-gnu - tuple: aarch64_be-unknown-linux-gnu - tuple: armv7-unknown-linux-gnueabihf - tuple: loongarch64-unknown-linux-gnu - tuple: powerpc-unknown-linux-gnu - tuple: powerpc64-unknown-linux-gnu - tuple: powerpc64le-unknown-linux-gnu - tuple: riscv32gc-unknown-linux-gnu - tuple: riscv64gc-unknown-linux-gnu - tuple: s390x-unknown-linux-gnu - tuple: x86_64-unknown-linux-gnu - tuple: aarch64-apple-darwin - tuple: aarch64-apple-ios-macabi ``` We definitely do not run *tests* for all of these targets on our CI. # Outcome We have decided to just subsume std_detect tests by our normal test suite for now, and not create a separate CI job. Therefore, this PR performs the following changes in target testing for `std_detect`: The following T3 targets would go from "build" to "nothing": ``` aarch64-unknown-freebsd (T3) armv6-unknown-freebsd (T3) powerpc-unknown-freebsd (T3) powerpc64-unknown-freebsd (T3) aarch64-unknown-openbsd (T3) ``` The following T3 targets would go from "test" to "nothing": ``` aarch64_be-unknown-linux-gnu (T3) riscv32gc-unknown-liux-gnu (T3) ``` The following T2 targets would go from "test" to "build": ``` arm-unknown-linux-gnueabihf (T2) armv7-unknown-linux-gnueabihf (T2) riscv64gc-unknown-linux-gnu (T2) powerpc-unknown-linux-gnu (T2) powerpc64-unknown-linux-gnu (T2) powerpc64le-unknown-linux-gnu (T2) s390x-unknown-linux-gnu (T2) i586-unknown-linux-gnu (T2) loongarch64-unknown-linux-gnu (T2) wasm32-wasip1 (T2) x86_64-apple-ios-macabi (T2) aarch64-apple-ios-macabi (T2) aarch64-pc-windows-msvc (T2) armv7-unknown-linux-gnueabihf (T2) loongarch64-unknown-linux-gnu (T2) powerpc-unknown-linux-gnu (T2) ``` I have confirmed in rust-lang/stdarch#1873 that the current version of this PR would pass stdarch's CI testsuite. r? `@ghost` try-job: armhf-gnu try-job: arm-android
This updates the rust-version file to 5a30e43.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 5a30e43 Filtered ref: 59749e9f8c765d3021796a9fe0c188643c4b8d77 This merge was created using https://github.com/rust-lang/josh-sync.
…isDenton Fix broken TLS destructors on 32-bit win7 Fixes rust-lang#141300 On the 32-bit win7 target, we use OS TLS instead of native TLS, due to issues with how the OS handles alignment. Unfortunately, this caused issues due to the TLS destructors not running, causing memory leaks among other problems. On Windows, to support OS TLS, the TlsAlloc family of function is used by Rust. This function does not support TLS destructors at all. However, rust has some code to emulate those destructors, by leveraging the TLS support functionality found in the MSVC CRT (specifically, in tlssup.c of the CRT). To use this functionality, the user must do two things: 1. They must put the address to their callback in a section between `.CRT$XLB` and `.CRT$XLY`. 2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to make sure the TLS support code in tlssup.c isn't garbage collected by the linker. Prior to this commit, this second bit wasn't being done properly by the Rust TLS support code. Instead of adding a reference to _tls_used, it instead had a reference to its own callback to prevent it from getting GC'd by the linker. While this is _also_ necessary, not having a reference on _tls_used made the entire support non-functional. This commit reworks the code to: 1. Add an unconditional `#[used]` attribute on the CALLBACK, which should be enough to prevent it from getting GC'd by the linker. 2. Add a reference to `_tls_used`, which should pull the TLS support code into the Rust programs and not let it be GC'd by the linker.
This primarily pulls in alexcrichton/dlmalloc-rs/55 and alexcrichton/dlmalloc-rs/54 to address 144199. Notably the highest byte in the wasm address space is no longer allocatable and additionally the allocator internally uses `wrapping_add` instead of `add` on pointers since on 32-bit platforms offsets might be larger than half the address space.
…ntentionally not `T: ?Sized`, and document (publically) an alternative.
This includes a qemu update from 8.2.2 to 9.2.1 which should hopefully fix some bugs we have encountered. PowerPC64LE is skipped for now because the new version seems to cause a number of new SIGILLs.
Wasm support has since been released, so we no longer need to depend on a git version of `object`.
We pretty often get at least one job failed because of failure to pull the musl git repo. Switch this to the unofficial mirror [1] which should be more reliable. Link: https://github.com/kraj/musl [1]
Update the last remaining image.
For this to work, the `QEMU_CPU=POWER8` configuration needed to be
dropped to avoid a new SIGILL. Doing some debugging locally, the crash
comes from an `extswsli` (per `powerpc:common64` in gdb-multiarch) in
the `ld64.so` available with PowerPC, which qemu rejects when set to
power8. Testing a build with `+crt-static` hits the same issue at a
`maddld` in `__libc_start_main_impl`.
Rust isn't needed to reproduce this:
$ cat a.c
#include <stdio.h>
int main() {
printf("Hello, world!\n");
}
$ powerpc64le-linux-gnu-gcc a.c
$ QEMU_CPU=power8 QEMU_LD_PREFIX=/usr/powerpc64le-linux-gnu/ ./a.out
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction
So the cross toolchain provided by Debian must have a power9 baseline
rather than rustc's power8. Alternatively, qemu may be incorrectly
rejecting these instructions (I can't find a source on whether or not
they should be available for power8). Testing instead with the `-musl`
toolchain and ppc linker from musl.cc works correctly.
In any case, things work with the default qemu config so it seems fine
to drop. The env was originally added in 5d164a4edafb ("fix the
powerpc64le target") but whatever the problem was there appears to no
longer be relevant.
Most of these were skipped because of a bug with the platform implementation, or some kind of crash unwinding. Since the upgrade to Ubuntu 25.04, these all seem to be resolved with the exception of a bug in the host `__floatundisf` [1]. [1] rust-lang/compiler-builtins#384 (comment)
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
…ibutes explicitly
…ctors_lite, r=ChrisDenton Stabilize `duration_constructors_lite` feature This closes [tracking issue](rust-lang#140881) and stabilises `Duration::from_hours` and `Duration::from_mins` while not touching a `duration_constructors` feature from the related [tracking issue (2)](rust-lang#120301)
…-section, r=joshtriplett
`{BTree,Hash}Map`: add "`Entry` API" section heading
I wanted to link to an introduction of the `Entry` API to the help message of `clippy::map_entry` (see rust-lang/rust-clippy#11598 for motivation), but I found the documentation on the `Entry` enum itself a bit short. On the other hand, `{BTree,Hash}Map` both have sections in their docs introducing the whole API and giving usage examples, and so I would like to link to that instead. For that, I introduce the "`Entry` API" section heading to both of them.
Do let me know whether you think this is the right approach.
…crum Replace unsafe `security_attributes` function with safe `inherit_handle` alternative The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe. In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
…nieu Constify remaining traits/impls for `const_ops` Tracking issue: rust-lang#143802 This is split into two commits for ease of reviewability: 1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before. 2. Actually constify the traits/impls. A few random other notes on the implementation specifically: * I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse. ---- As far as the actual changes go, this constifies the following additional traits: * `Neg` * `Not` * `BitAnd` * `BitOr` * `BitXor` * `Shl` * `Shr` * `AddAssign` * `SubAssign` * `MulAssign` * `DivAssign` * `RemAssign` * `BitAndAssign` * `BitOrAssign` * `BitXorAssign` * `ShlAssign` * `ShrAssign` In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives. Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead) There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives. * `Duration` (arithmetic operations) * `SystemTime` (arithmetic operations) * `Ipv4Addr` (bit operations) * `Ipv6Addr` (bit operations) Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang#144517. Stuff left out of this PR: * `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out) * `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful) * `SystemTime` (will submit separate PR) * SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467) <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_CONCERN-ISSUE_START --> > [!NOTE] > # Concerns (0 active) > > - ~~[May break Clippy](rust-lang#143949 (comment) resolved in [this comment](rust-lang#143949 (comment)) > > *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.* <!-- TRIAGEBOT_CONCERN-ISSUE_END --> <!-- TRIAGEBOT_END -->
…=Amanieu document assumptions about `Clone` and `Eq` traits Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at rust-lang/hashbrown#629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere. I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then ```text x == x -> x.clone() == x ``` is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation. As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow. An additional thought of mine: If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.
…olasbishop std: sys: io: io_slice: Add UEFI types UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation. Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST. cc ``@nicholasbishop``
…htriplett Remove unnecessary parentheses in `assert!`s
Use a time representation with 1900-01-01-00:00:00 at timezone -1440 min as anchor. This is the earliest time supported in UEFI. Signed-off-by: Ayush Singh <[email protected]>
Add tests to ensure that extream system times are still representable. Signed-off-by: Ayush Singh <[email protected]>
This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`. Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
…r=dtolnay Make explicit guarantees about `Vec`’s allocator This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`. Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
Fix a typo in range docs
|
It seems that we are compiling the standard library with rustc version provided by the host (which has 1.88), not the rustc version set by our |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is an automated PR to merge library subtree updates from 2025-08-07 (rust-lang/rust@7d82b83) to 2025-08-14 (rust-lang/rust@3672a55), inclusive. This is a clean merge, no conflicts were detected. Do not remove or edit the following annotations:
git-subtree-dir: library
git-subtree-split: aad53ec