Merge subtree update for toolchain nightly-2025-04-21 #336
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}
…uviper Recognise new IPv6 non-global range from IETF RFC 9602 This PR adds the `5f00::/16` range defined by [IETF RFC 9602](https://datatracker.ietf.org/doc/rfc9602/) to those ranges which `Ipv6Addr::is_global` recognises as a non-global IP. This range is used for Segment Routing (SRv6) SIDs. See also: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml Unstable tracking issue: rust-lang#27709
I noticed that `PartialOrd` implementation for `bool` does not override the individual operator methods, unlike the other primitive types like `char` and integers. This commit extracts these `PartialOrd` overrides shared by the other primitive types into a macro and calls it on `bool` too.
add FCW to warn about wasm ABI transition See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following: - scalar arguments are fine - including 128 bit types, they get passed as two `i64` arguments in both ABIs - `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes) - all return values are fine `@bjorn3` `@alexcrichton` `@Manishearth` is that correct? I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this? IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments. Tracking issue: rust-lang#138762 Transition plan blog post: rust-lang/blog.rust-lang.org#1531 try-job: dist-various-2
…Poison,saethlin Trusty: Fix build for anonymous pipes and std::sys::process PRs rust-lang#136842 (Add libstd support for Trusty targets), rust-lang#137793 (Stablize anonymous pipe), and rust-lang#136929 (std: move process implementations to `sys`) merged around the same time, so update Trusty to take them into account. cc `@randomPoison`
…, r=scottmcm Override PartialOrd methods for bool I noticed that `PartialOrd` implementation for `bool` does not override the individual operator methods, unlike the other primitive types like `char` and integers. This commit extracts these `PartialOrd` overrides shared by the other primitive types into a macro and calls it on `bool` too. CC `@scottmcm` for our recent adventures in `PartialOrd` land
Rollup of 11 pull requests Successful merges: - rust-lang#138128 (Stabilize `#![feature(precise_capturing_in_traits)]`) - rust-lang#138834 (Group test diffs by stage in post-merge analysis) - rust-lang#138867 (linker: Fix staticlib naming for UEFI) - rust-lang#138874 (Batch mark waiters as unblocked when resuming in the deadlock handler) - rust-lang#138875 (Trusty: Fix build for anonymous pipes and std::sys::process) - rust-lang#138877 (Ignore doctests only in specified targets) - rust-lang#138885 (Fix ui pattern_types test for big-endian platforms) - rust-lang#138905 (Add target maintainer information for powerpc64-unknown-linux-musl) - rust-lang#138911 (Allow defining opaques in statics and consts) - rust-lang#138917 (rustdoc: remove useless `Symbol::is_empty` checks.) - rust-lang#138945 (Override PartialOrd methods for bool) r? `@ghost` `@rustbot` modify labels: rollup
Change the syntax to include parameter names and a trailing semicolon. Motivation: - Mirror the `syscall!` macro. - Allow rustfmt to format it (when wrapped in parentheses). - For better documentation (having the parameter names available in the source code is a bit nicer). - Allow future improvements to this macro where we can sometimes use the symbol directly when it's statically known to be available.
Encodes the safety constraint that `Unique`'s pointer must be non-zero into the API.
Removes some unsafety and reduces the number of `usize` -> `ptr` transmutes which might be helpful for CHERI-like targets in the future.
We haven't had any Windows XP targets for a long while now...
…lacrum Allow spawning threads after TLS destruction Fixes rust-lang#138696
Currently, `write` for stdout and stderr on Trusty is implemented with the semantics of `write_all`. Instead, call the underlying syscall only once in `write` and use the default implementation of `write_all` like other platforms. Also, implement `write_vectored` by adding support for `IoSlice`. Refactor stdin to reuse the unsupported type like rust-lang#136769.
…Denton std: get rid of pre-Vista fallback code We haven't had any Windows XP targets for a long while now... r? ChrisDenton
Signed-off-by: xizheyin <[email protected]>
By marking `__errno_location` as `#[ffi_const]` and `std::sys::os::errno` as `#[inline]`, this PR allows merging multiple calls to `io::Error::last_os_error()` into one.
Explain one-past-the-end pointer in std library Closing rust-lang#138969 r? libs
Put pin!() tests in the right file. In rust-lang#138717, these tests were put in `tests/pin.rs`, but they should go in `tests/pin_macro.rs`. r? `@jdonszelmann`
Fix formatting nit in process.rs Minor formatting issue in `process.rs`.
Miri subtree update r? `@ghost`
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.
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
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``
tautschnig
approved these changes
Apr 22, 2025
carolynzech
approved these changes
Apr 22, 2025
tautschnig
approved these changes
Apr 22, 2025
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-07 (rust-lang/rust@2fa8b11) to 2025-04-21 (rust-lang/rust@b8c54d6) (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: 2ab28f3