Update subtree/library to 2026-03-02 - #636
Open
github-actions[bot] wants to merge 308 commits into
Open
Conversation
(cherry picked from commit b901497)
This is similar to prior updates such as 149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however: * The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean. * In 147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as 149864, 150291, and 151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed. Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
…, r=folkertdev stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@1a7cc47. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…ouxu Update wasi-sdk used in CI/releases This is similar to prior updates such as rust-lang#149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however: * The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean. * In rust-lang#147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as rust-lang#149864, rust-lang#150291, and rust-lang#151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed. Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
…nathanBrouwer Rollup of 6 pull requests Successful merges: - rust-lang#151590 (cmse: don't use `BackendRepr` when checking return type) - rust-lang#151945 (feat: Add `NonZero::<T>::from_str_radix`) - rust-lang#152000 (Fix ICE in normalizing inherent associated consts with `#[type_const]`) - rust-lang#152192 (Always use Xcode-provided Clang in macOS CI) - rust-lang#152196 (bootstrap: Remove `ShouldRun::paths`) - rust-lang#152222 (Re-add TaKO8Ki to triagebot review queue)
There are some permission changes that are causing the runners to fail to launch. Link: IBM/actionspz#75
In recent nightlies we are hitting errors like the following:
error: an associated constant with this name may be added to the standard library in the future
--> libm/src/math/support/float_traits.rs:248:48
|
248 | const SIGN_MASK: Self::Int = 1 << (Self::BITS - 1);
| ^^^^^^^^^^
...
324 | / float_impl!(
325 | | f32,
326 | | u32,
327 | | i32,
... |
333 | | fmaf32
334 | | );
| |_- in this macro invocation
|
= warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
= note: for more information, see issue rust-lang#48919 <rust-lang#48919>
= note: `-D unstable-name-collisions` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unstable_name_collisions)]`
= note: this error originates in the macro `float_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: use the fully qualified path to the associated const
|
248 - const SIGN_MASK: Self::Int = 1 << (Self::BITS - 1);
248 + const SIGN_MASK: Self::Int = 1 << (<f32 as float_traits::Float>::BITS - 1);
|
help: add `#![feature(float_bits_const)]` to the crate attributes to enable `core::f32::<impl f32>::BITS`
--> libm/src/lib.rs:26:1
|
26 + #![feature(float_bits_const)]
|
Using fully qualified syntax is verbose and `BITS` only exists since
recently, so allow this lint instead.
stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter` and the `core::range` module
This was left over from f6a23a78c44e ("fmaximum,fminimum: Fix incorrect
result and add tests").
[ added context to body - Trevor ]
The acosh functions were incorrectly returning finite values for some negative inputs (should be NaN for any `x < 1.0`) The bug was inherited when originally ported from musl, and this patch follows their fix for single-precision acoshf in [1]. A similar fix is applied to acosh, though musl still has an incorrect implementation requiring tests against that basis to be skipped. [1]: https://git.musl-libc.org/cgit/musl/commit/?id=c4c38e6364323b6d83ba3428464e19987b981d7a [ added context to message - Trevor ]
This allows us to drop wasm-specific configuration for `getrandom`. Link: https://github.com/rust-random/getrandom/blob/314fd5ab3e6d9ef2ec90243894731865a725417d/CHANGELOG.md#major-change-to-wasm_js-backend
The build time isn't very different so we can keep things simpler.
Ensure that these are actually doing what is expected.
…jhpratt Stabilize `atomic_try_update`and deprecate `fetch_update` starting 1.99.0 Tracking issue: rust-lang#135894 FCP completed: rust-lang#135894 (comment) ~1.96.0 was chosen because I don't think the remaining month until 1.93.0 becomes beta is enough for the FCP to finish and this to get merged, so 1.94.0 + a couple of versions of leeway: rust-lang#135894 (comment) 1.99 suggested in rust-lang#148590 (comment) Closes rust-lang#135894
…, r=tgross35 Stabilize new inclusive range type and iterator type Part 1 of stabilizing the new range types for rust-lang#125687 stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API: ```rust // in core and std pub mod range; // in core::range pub struct RangeInclusive<Idx> { pub start: Idx, pub last: Idx, } impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ } impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> { pub const fn contains<U>(&self, item: &U) -> bool where Idx: [const] PartialOrd<U>, U: ?Sized + [const] PartialOrd<Idx>; pub const fn is_empty(&self) -> bool where Idx: [const] PartialOrd; } impl<Idx: Step> RangeInclusive<Idx> { pub fn iter(&self) -> RangeInclusiveIter<Idx>; } impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ } impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ } impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ } impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ } pub struct RangeInclusiveIter<A>(/* ... */); impl<A: Step> RangeInclusiveIter<A> { pub fn remainder(self) -> Option<RangeInclusive<A>>; } impl<A: Step> Iterator for RangeInclusiveIter<A> { type Item = A; /* ... */ } impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ } impl<A: Step> FusedIterator for RangeInclusiveIter<A> { } impl<A: Step> IntoIterator for RangeInclusive<A> { type Item = A; type IntoIter = RangeInclusiveIter<A>; /* ... */ } impl ExactSizeIterator for RangeInclusiveIter<u8> { } impl ExactSizeIterator for RangeInclusiveIter<i8> { } unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> { type Output = [T]; /* ... */ } unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> { type Output = str; /* ... */ } ``` I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.
…scii, r=dtolnay feat: Implement `int_from_ascii` for `NonZero<T>` - Tracking issue: rust-lang#134821 This pull request adds `from_ascii` and `from_ascii_radix` methods to `NonZero<T>` that parses a non-zero integer from an ASCII-byte slice (`&[u8]`) with decimal digits or digits in a given base. When using the combination of `int::from_ascii` or `int::from_ascii_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error. `NonZero::<T>::from_str_radix` and `NonZero::<T>::from_str` require a string (`&str`) as a parameter. ```rust // Cannot return `IntErrorKind::Zero` as an error. assert_eq!(NonZero::new(u8::from_ascii(b"0").unwrap()), None); // Can return `IntErrorKind::Zero` as an error. let err = NonZero::<u8>::from_ascii(b"0").unwrap_err(); assert_eq!(err.kind(), &IntErrorKind::Zero); ``` See also rust-lang#152193
…pratt Stabilize `core::hint::cold_path` `cold_path` has been around unstably for a while and is a rather useful tool to have. It does what it is supposed to and there are no known remaining issues, so stabilize it here (including const). Newly stable API: ```rust // in core::hint pub const fn cold_path(); ``` I have opted to exclude `likely` and `unlikely` for now since they have had some concerns about ease of use that `cold_path` doesn't suffer from. `cold_path` is also significantly more flexible; in addition to working with boolean `if` conditions, it can be used in `match` arms, `if let`, closures, and other control flow blocks. `likely` and `unlikely` are also possible to implement in user code via `cold_path`, if desired. Closes: rust-lang#136873 (tracking issue) --- There has been some design and implementation work for making `#[cold]` function in more places, such as `if` arms, `match` arms, and closure bodies. Considering a stable `cold_path` will cover all of these usecases, it does not seem worth pursuing a more powerful `#[cold]` as an alternative way to do the same thing. If the lang team agrees, then: Closes: rust-lang#26179 Closes: rust-lang#120193
The recent switch in default mangling meant that the check was no longer working correctly. Resolve this by checking for both legacy- and v0-mangled core symbols to the extent that this is possible.
We have a handful of repeated dependencies that can be cleaned up, so change here.
This reverts commit ce4c17f.
…od, r=madsmtm deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls The `Eq::assert_receiver_is_total_eq` method is purely meant as an implementation detail by `#[derive(Eq)]` to add checks that all fields of the type the derive is applied to also implement `Eq`. The method is already `#[doc(hidden)]` and has a comment saying `// This should never be implemented by hand.`. Unfortunately, it has been stable since 1.0 and there are some cases on GitHub (https://github.com/search?q=assert_receiver_is_total_eq&type=code) where people have implemented this method manually, sometimes even with actual code in the method body (example: https://github.com/Shresht7/codecrafters-redis-rust/blob/31f0ec453c504b4ab053a7b1c3ff548ff36a9db5/src/parser/resp/types.rs#L255). To prevent further confusion from this, this PR is deprecating the method and adds a FCW when it is manually implemented (this is necessary as the deprecation warning is not emitted when the method is implemented, only when it is called). This is similar to what was previously done with the `soft_unstable` lint (rust-lang#64266). See also rust-lang/libs-team#704.
…-self, r=JonathanBrouwer Remove redundant self usages Extracted from rust-lang#152996. r? petrochenkov
- Based on Windows implementation. Just removed support for quote escaping since that is not supported in UEFI. - Tested using OVMF on QEMU Signed-off-by: Ayush Singh <ayush@beagleboard.org>
- Add test for split_paths for UEFI target. - `;` is the path separator. Escaping is not supported. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Revert "Simplify internals of `{Rc,Arc}::default`"
This reverts rust-lang#152591 following a [perf run being done](rust-lang#152591 (comment)). I'm not really positioned at this time to dive in further and understand the performance regressions, so I'll back away from `Rc`/`Arc` and leave them as-is.
Prepare NonNull for pattern types Pull out the changes that affect some tests, but do not require pattern types. See rust-lang#136006 (comment) for what triggered this PR r? @scottmcm
…iper Improved security section in rustdoc for `current_exe` A few improvements to the security section of the docs about `current_exe` 0. The explanatory link <https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183> is ~~broken~~ not directly very helpful in understanding the risk. 1. It basically previously says to never trust the result, which is IMO too pessimistic to be helpful. It's worth understanding the behavior but if you have a use case to re-exec the current program, which is not uncommon, this is a reasonable way to do it. 2. The particular risk is about setuid/setgid processes that shouldn't fully trust the user that spawned them. 3. IMO the most important risk with this function is that the invoker can control argv and PATH, so I made this more explicit. (Many unixes, including Linux, don't rely on them in the implementation, but some do.) 4. The previous text about TOCTOU and races is IMO not really coherent: if an attacker can write to the location where you're going to re-exec, they can fundamentally control what program is executed. They don't need to race with your execution of current_exe, and there is no up-front check. 5. Briefly explain the pattern of CVE-2009-1894: on Linux, depending on system configuration, an attacker who can create hardlinks to the executable can potentially control `/proc/self/exe`. On modern Linux this should normally require permission to write to the executable. I did some web research for "argv0 vulnerability" and similar terms and didn't find anything else we should be documenting here. (There are issues about argc=0 but those should be prevented by memory safety in Rust.) I found what the link seemed to be pointing to in <https://vulners.com/cve/CVE-2009-1894>, which talks about confusing a setuid program by creating a hardlink to its exe. I think this is in very particular circumstances something people should still be concerned about: a setuid program on a machine with `fs.protected_hardlinks = 0`. I don't think this justifies warning people not to use the function at all. cc @mgeisler
…essage, r=RalfJung Fix mem::conjure_zst panic message to use any::type_name instead Use `crate::any::type_name::<T>()` instead of `stringify!(T)` in the runtime panic message of `conjure_zst` , so the actual type name (e.g. `i32`) is shown rather than the literal string `[T]`.
…oboet Recover feature lang_items for emscripten Fixes rust-lang#152469 (comment)
These doctests are attached to the `TryFrom` trait. Therefore, it is easier to understand to use the `try_from` method instead of the `try_into` method.
These doctests are attached to the `From` trait. Therefore, it is easier to understand to use the `from` method instead of the `into` method.
…nathanBrouwer Rollup of 12 pull requests Successful merges: - rust-lang#151143 (explicit tail calls: support indirect arguments) - rust-lang#153012 (Stop using `LinkedGraph` in `lexical_region_resolve`) - rust-lang#153175 (Clarify a confusing green-path function) - rust-lang#153179 (Force a CI LLVM stamp bump) - rust-lang#150828 (Improved security section in rustdoc for `current_exe`) - rust-lang#152673 (rustc_public: rewrite `bridge_impl` to reduce boilerplate) - rust-lang#152674 (rustc_public: remove the `CrateDefItems` trait) - rust-lang#153073 (Fix mem::conjure_zst panic message to use any::type_name instead) - rust-lang#153117 (Remove mutation from macro path URL construction) - rust-lang#153128 (Recover feature lang_items for emscripten) - rust-lang#153138 (Print path root when printing path) - rust-lang#153159 (Work around a false `err.emit();` type error in rust-analyzer)
…-item, r=oli-obk add field representing types *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152730)* > [!NOTE] > This is a rewrite of rust-lang#146307 by using a lang item instead of a custom `TyKind`. We still need a `hir::TyKind::FieldOf` variant, because resolving the field name cannot be done before HIR construction. The advantage of doing it this way is that we don't need to make any changes to types after HIR (including symbol mangling). At the very beginning of this feature implementation, I tried to do it using a lang item, but then quickly abandoned the approach, because at that time I was still intending to support nested fields. Here is a [range-diff](https://triagebot.infra.rust-lang.org/gh-range-diff/rust-lang/rust/605f49b27444a738ea4032cb77e3bdc4eb811bab..d15f5052095b3549111854a2555dd7026b0a729e/605f49b27444a738ea4032cb77e3bdc4eb811bab..f5f42d1e03495dbaa23671c46b15fccddeb3492f) between the two PRs --- # Add Field Representing Types (FRTs) This PR implements the first step of the field projection lang experiment (Tracking Issue: rust-lang#145383). Field representing types (FRTs) are a new kind of type. They can be named through the use of the `field_of!` macro with the first argument being the type and the second the name of the field (or variant and field in the case of an enum). No nested fields are supported. FRTs natively implement the `Field` trait that's also added in this PR. It exposes information about the field such as the type of the field, the type of the base (i.e. the type that contains the field) and the offset within that base type. Only fields of non-packed structs are supported, fields of enums an unions have unique types for each field, but those do not implement the `Field` trait. This PR was created in collaboration with @dingxiangfei2009, it wouldn't have been possible without him, so huge thanks for mentoring me! I updated my library solution for field projections to use the FRTs from `core` instead of creating my own using the hash of the name of the field. See the [Rust-for-Linux/field-projection `lang-experiment` branch](https://github.com/Rust-for-Linux/field-projection/tree/lang-experiment). ## API added to `core::field` ```rust pub unsafe trait Field { type Base; type Type; const OFFSET: usize; } pub macro field_of($Container:ty, $($fields:expr)+ $(,)?); ``` Along with a perma-unstable type that the compiler uses in the expansion of the macro: ```rust #[unstable(feature = "field_representing_type_raw", issue = "none")] pub struct FieldRepresentingType<T: ?Sized, const VARIANT: u32, const FIELD: u32> { _phantom: PhantomData<T>, } ``` ## Explanation of Field Representing Types (FRTs) FRTs are used for compile-time & trait-level reflection for fields of structs & tuples. Each struct & tuple has a unique compiler-generated type nameable through the `field_of!` macro. This type natively contains information about the field such as the outermost container, type of the field and its offset. Users may implement additional traits on these types in order to record custom information (for example a crate may define a [`PinnableField` trait](https://github.com/Rust-for-Linux/field-projection/blob/lang-experiment/src/marker.rs#L9-L23) that records whether the field is structurally pinned). They are the foundation of field projections, a general operation that's generic over the fields of a struct. This genericism needs to be expressible in the trait system. FRTs make this possible, since an operation generic over fields can just be a function with a generic parameter `F: Field`. > [!NOTE] > The approach of field projections has changed considerably since this PR was opened. In the end we might not need FRTs, so this API is highly experimental. FRTs should act as though they were defined as `struct MyStruct_my_field<StructGenerics>;` next to the struct. So it should be local to the crate defining the struct so that one can implement any trait for the FRT from that crate. The `Field` traits should be implemented by the compiler & populated with correct information (`unsafe` code needs to be able to rely on them being correct). ## TODOs There are some `FIXME(FRTs)` scattered around the code: - Diagnostics for `field_of!` can be improved - `tests/ui/field_representing_types/nonexistent.rs` - `tests/ui/field_representing_types/non-struct.rs` - `tests/ui/field_representing_types/offset.rs` - `tests/ui/field_representing_types/not-field-if-packed.rs` - `tests/ui/field_representing_types/invalid.rs` - Simple type alias already seem to work, but might need some extra work in `compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs` r? @oli-obk
…rite, r=Mark-Simulacrum refactor 'valid for read/write' definition: exclude null This is an attempt to resolve rust-lang#138351. The underlying problem is that when we decided to allow reads/writes/copies of size 0 even for null pointers, we documented that by changing the definition of "valid for read/write" in the standard library to say that null pointers are valid for 0-sized reads/writes. Unfortunately, that definition is also used in other places that assume that a valid-for-read/write pointer can be converted into a reference, and of course that's UB if the pointer is null, even if the pointee is a ZST. The proposal for fixing this is to make "valid for reads/writes" slightly [weaker](https://faultlore.com/blah/tower-of-weakenings/) than it has to be, and require the pointer to be non-null, and then to add exceptions to the most basic functions (read/write/copy) to explicitly allow arbitrary pointers when the size is 0. This isn't pretty but it's the best solution that has been suggested so far I think. Cc @rust-lang/opsem @rust-lang/libs-api
* docs: explicitly list env vars checked by temp_dir on Windows On Windows, temp_dir() internally calls GetTempPath2/GetTempPath which checks TMP, TEMP, USERPROFILE environment variables in order. This information was previously only available by following links to Microsoft docs. Making it explicit in Rust's own documentation improves discoverability. Addresses rust-lang#125439. * docs: note env var influence on temp_dir and env_clear on Windows On Windows, �nv::temp_dir() internally calls GetTempPath2/GetTempPath, which checks TMP, TEMP, and USERPROFILE in order. Document this lookup order directly in the emp_dir docs rather than requiring users to follow the link to Microsoft documentation. Also add a note on Command::env_clear explaining that clearing the environment affects the child process's emp_dir(), not the parent's. Closes rust-lang#125439. * docs: drop Windows env_clear temp_dir note
std: sys: pal: uefi: os: Implement split_paths - Tested using OVMF on QEMU @rustbot label +O-UEFI cc @nicholasbishop
std random.rs: update link to RTEMS docs The old URL with `master` resulted in a 404 error - use `main` instead.
…s, r=Mark-Simulacrum docs: note env var influence on `temp_dir` and `env_clear` on Windows On Windows, `env::temp_dir()` internally calls `GetTempPath2`/`GetTempPath`, which checks the `TMP`, `TEMP`, and `USERPROFILE` environment variables in order before falling back to the Windows directory. This lookup order was previously only discoverable by following links to Microsoft documentation. This PR documents the env var lookup order directly in `env::temp_dir` docs and notes `GetTempPath2`'s SYSTEM-identity behavior (`C:\Windows\SystemTemp`). Addresses rust-lang#125439.
… r=joboet style: Update doctests for `TryFrom<integer> for bool` and `From<bool> for float` These doctests are attached to the `TryFrom` trait and the `From` trait. Although `From<U> for T` implies `Into<T> for U` and `TryFrom<U> for T` implies `TryInto<T> for U`, I think it is easier to understand to use the `try_from`/`from` method directly instead of the `try_into`/`into` method.
…Mark-Simulacrum std: move `getpid` to `sys::process` Part of rust-lang#117276. Availability of process IDs is highly correlated with availability of processes, so moving the `getpid` implementations to `sys::process` makes a lot of sense (and removes quite some code duplication). The only notable change here is on Hermit, which doesn't have processes but does have `getpid`. But that [always returns 0](https://github.com/hermit-os/kernel/blob/ef27b798856b50d562a42c4ffd2edcb7493c5b5f/src/syscalls/tasks.rs#L21), so I doubt it is useful. If the change to a panic is problematic we could always copy the stub implementation and return zero ourselves (this also applies to the other single-process platforms). CC @stlankes @mkroening
Fix compile error in std::fs impl on VEXos target This PR fixes a compile error in the standard library on the `armv7a-vex-v5` target that was caused by there not being a version of the `Dir` struct exported from `std::sys::fs::vexos`. Reading from directories isn't supported on this platform, so the module now re-exports the unsupported version of `Dir`.
…oboet Recover feature lang_items for emscripten Fixes rust-lang#152469 (comment) The previous rust-lang#153128 lacks of `feature`
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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 update the subtree/library branch to the changes from 2025-11-25 (rust-lang/rust@c871d09) to 2026-03-02 (rust-lang/rust@8038127), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git pushto literally push the changes tosubtree/librarywithout any rebase or merge.