Merge subtree update for toolchain nightly-2025-05-17 #40
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 were roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms.
Also mention them from `as_flattened(_mut)`.
Implement `pin!()` using `super let` Tracking issue for super let: rust-lang#139076 This uses `super let` to implement `pin!()`. This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596. It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field. While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable. It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
Implement `Default` for raw pointers ACP: rust-lang/libs-team#571 This is instantly stable so we will need an FCP here. Closes rust-lang/rfcs#2464
fix incorrect type in cstr `to_string_lossy()` docs Restoring what it said prior to commit 67065fe in which it was changed incorrectly with no supporting explanation. Closes rust-lang#139835.
std: Use fstatat() on illumos
…=joboet Move `pal::env` to `std::sys::env_consts` Combine the `std::env::consts` platform implementations as a single file. Use the Unix file as the base, since it has 28 entries, and fold the 8 singleton platforms into it. The Unix file was roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms. I'd prefer to have no fallback implementation, as I consider it a bug; however TEEOS, Trusty, and Xous have no definitions here. Since they otherwise have `pal` abstractions, that indicates that there are several platforms without `pal` abstractions which are also missing here. To support unsupported, create a little macro to handle the fallback case and not introduce ordering between the `cfg`s like `cfg_if!`. I've named the module `std::sys::env_consts`, because they are used in `std::env::consts` and I intend to use the name `std::sys::env` for the combination of `Args` and `Vars`. cc `@joboet` `@ChrisDenton` Tracked in rust-lang#117276.
add next_index to Enumerate Proposal: rust-lang/libs-team#435 Tracking Issue: rust-lang#130711 This basically just reopens rust-lang#130682 but squashed and with the new function and the feature gate renamed to `next_index.` There are two questions I have already: - Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be. - Maybe I could actually also add a doctest? - For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
…enton Rollup of 8 pull requests Successful merges: - rust-lang#138934 (support config extensions) - rust-lang#139091 (Rewrite on_unimplemented format string parser.) - rust-lang#139753 (Make `#[naked]` an unsafe attribute) - rust-lang#139762 (Don't assemble non-env/bound candidates if projection is rigid) - rust-lang#139834 (Don't canonicalize crate paths) - rust-lang#139868 (Move `pal::env` to `std::sys::env_consts`) - rust-lang#139978 (Add citool command for generating a test dashboard) - rust-lang#139995 (Clean UI tests 4 of n) r? `@ghost` `@rustbot` modify labels: rollup
…rrently written into Signed-off-by: xizheyin <[email protected]>
…affleLapkin simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors It's not clear at all why the mask would have to be signed, it is anyway interpreted bitwise. The backend should just make sure that works no matter the surface-level type; our LLVM backend already does this correctly. The note of "the mask may be widened, which only has the correct behavior for signed integers" explains... nothing? Why can't the code do the widening correctly? If necessary, just cast to the signed type first... Also while we are at it, fix the errors. For simd_masked_load/store, the errors talked about the "third argument" but they meant the first argument (the mask is the first argument there). They also used the wrong type for `expected_element`. I have extremely low confidence in the GCC part of this PR. See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/On.20the.20sign.20of.20masks)
docs: fix typo change from inconstants to invariants
Co-authored-by: Jonas Böttiger <[email protected]>
Add target-specific NaN payloads for the missing tier 2 targets This PR adds target-specific NaN payloads for the remaining tier 2 targets: - `arm64ec`: This target is a mix of `x86_64` and `aarch64`, meaning as they both have no extra payloads `arm64ec` also has no extra payloads. - `loongarch64`: Per [LoongArch Reference Manual - Volume 1: Basic Architecture](https://github.com/loongson/LoongArch-Documentation/releases/download/2023.04.20/LoongArch-Vol1-v1.10-EN.pdf) section 3.1.1.3, LoongArch does quieting NaN propagation with the Rust preferred NaN as its default NaN, meaning it has no extra payloads. - `nvptx64`: Per [PTX ISA documentation](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions) section 9.7.3 (and section 9.7.4 for `f16`), all payloads are possible. The documentation explicitly states that `f16` and `f32` operations result in an unspecified NaN payload, while for `f64` it states "NaN payloads are supported" without specifying how or what payload will be generated if there are no input NaNs. - `powerpc` and `powerpc64`: Per [Power Instruction Set Architecture](https://files.openpower.foundation/s/9izgC5Rogi5Ywmm/download/OPF_PowerISA_v3.1C.pdf) Book I section 4.3.2, PowerPC does quieting NaN propagation with the Rust preferred NaN being generated if no there are no input NaNs, meaning it has no extra payloads. - `s390x`: Per [IBM z/Architecture Principles of Operation](https://www.vm.ibm.com/library/other/22783213.pdf#page=965) page 9-3, s390x does quieting NaN propagation with the Rust's preferred NaN as its default NaN, meaning it has no extra payloads. Tracking issue: rust-lang#128288 cc ``@RalfJung`` ``@rustbot`` label +T-lang Also cc relevant target maintainers of tier 2 targets: - `arm64ec`: ``@dpaoliello`` - `loongarch64`: ``@heiher`` ``@xiangzhai`` ``@zhaixiaojuan`` ``@xen0n`` - `nvptx64`: ``@RDambrosio016`` ``@kjetilkjeka`` - `powerpc`: the only documented maintainer is ``@BKPepe`` for the tier 3 `powerpc-unknown-linux-muslspe`. - `powerpc64`: ``@daltenty`` ``@gilamn5tr`` ``@Gelbpunkt`` ``@famfo`` ``@neuschaefer`` - `s390x`: ``@uweigand`` ``@cuviper``
…ss35 Fix backtrace for cygwin Closes rust-lang#140304 Depends on: - [x] rust-lang/backtrace-rs#704 This PR could not be merged until the above PR is merged. I'll update the submodule then. EDIT: submodule updated.
Update `compiler-builtins` to 0.1.158 Includes the following changes: * Require `target_has_atomic = "ptr"` for runtime feature detection [1] [1]: rust-lang/compiler-builtins#909
…r-cleanup, r=notriddle [rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed Fixes rust-lang#139899. The bug was due to the fact that if any doctest fails for any reason, we call `exit` (or it's called inside `libtest` if not edition 2024), meaning that `TempDir`'s destructor isn't called, and therefore the temporary folder isn't cleaned up. Took me a while to figure out how to reproduce but finally I was able to reproduce the bug with: `````rust #![doc(test(attr(deny(warnings))))] //! ``` //! let a = 12; //! ``` ````` And then I ensured that panicking doctests were cleaned up as well: `````rust //! ``` //! panic!(); //! ``` ````` And finally I checked if it was fixed for merged doctests too (`--edition 2024`). To make this work, I needed to add a new public function in `libtest` too which would call a function once all tests have been run. So only issue is: I have absolutely no idea how we can add a regression test for this fix. If anyone has an idea... r? `@notriddle`
Fix regression from rust-lang#140393 for espidf / horizon / nuttx / vita rust-lang#140393 introduced changes to the layout of the `std::sys::process` code. As a result, the Tier 3 ESP-IDF (and I suspect Horizon, Nuttx and Vita targets as well) no longer build. A `pub use unsupported::output` is all that was missing - for the above OSes specifically. This explicit `pub use` is now necessary, because rust-lang#140393 moved the `output` function to module-level, where it was previously part of `Command` and was thus re-exported automatically, as part of the `imp::Command` re-export further down the file containing the one-liner fix. Note that - with the change introduced by rust-lang#140393 - we **can't** anymore just do an unconditional `pub use imp::output` as this function simply does not exist anymore anywhere else but in the `unsupported` module. r? `@joboet`
Explicitly point out that if the function panics the init function might be called multiple times.
[win][arm64] Disable std::fs tests that require symlinks While trying to get the aarch64-msvc build working correctly (rust-lang#140136), various tests in `std::fs` were failing as the Arm64 Windows runner image we are using does not have Developer Mode enabled, thus it cannot create symlinks. I've [filed a request to get Developer Mode enabled](actions/partner-runner-images#94), but in the meantime I've disabled the relevant tests on Arm64 Windows.
And note that the same limitation applies to all LLVM-based compilers Co-authored-by: Ralf Jung <[email protected]>
…ulacrum Clarify black_box warning a bit Trying to bring the docs on black_box more in line with the advice that we have discussed in Zulip. rust-lang#140341 (comment)
… r=Amanieu Implement (part of) ACP 429: add `DerefMut` to `Lazy[Cell/Lock]` `DerefMut` is instantly stable, as a trait impl. That means this needs an FCP. ``@rustbot`` label +needs-fcp rust-lang/libs-team#429
…ntrinsic, r=Mark-Simulacrum remove intrinsics::drop_in_place This was only ever accidentally stable, and has been marked as deprecated since Rust 1.52, released almost 4 years ago. We've removed the old serialization `derive`s, maybe we can remove this one as well? As suggested by ``@jhpratt,`` let's see what crater says for this one.
remove 'unordered' atomic intrinsics As their doc comment already indicates, these operations do not currently have a place in our memory model. The intrinsics were introduced to support a hack in compiler-builtins, but that hack recently got removed (see rust-lang/compiler-builtins#788).
Update documentation of OnceLock::get_or_init. Explicitly point out that if the function panics the init function might be called multiple times.
…-Simulacrum Update hermit-abi to 0.5.1 This updates hermit-abi to version 0.5.1, bringing the [recent `AF_*`](rust-lang/libc#4344) changes to std.
…r=scottmcm,traviscross,tgross35
Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations
This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations.
This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them.
Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`.
r? `@tgross35`
try-job: aarch64-gnu
try-job: dist-various-1
try-job: dist-various-2
[^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
…_lite, r=BurntSushi Split duration_constructors to get non-controversial constructors out This implements rust-lang#140881
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-04-24 (rust-lang/rust@df35ff6) to 2025-05-17 (rust-lang/rust@16d2276) (inclusive) into main.
git mergeresulted in conflicts, which require manual resolution. Files were commited with merge conflict markers. Do not remove or edit the following annotations:git-subtree-dir: library
git-subtree-split: 4356e4b