Merge subtree update for toolchain nightly-2025-05-06 #354
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}
…mulacrum std: Fix build for NuttX targets Fix std build for all NuttX targets. It is the single largest set of failures on <https://does-it-build.noratrieb.dev/>. Although, ESP-IDF also requires these same gates, there are other issues for those targets. This can verified be running `x check library/std --target=` for all NuttX targets. cc ``@no1wudi``
…ulacrum libtest: Pass the test's panic payload as Option instead of Result Passing a `Result<(), &dyn Any>` to `calc_result` requires awkward code at both call sites to build a fake result, for no real benefit. It's much easier to just pass the payload as `Option<&dyn Any>`. No functional change.
…=Mark-Simulacrum update ```miniz_oxide``` to 0.8.8 I would normally let the auto actions handle this but it turns out 0.8.7 can trigger a panic when debug assertions are enabled in a few cases so I feel it's important it gets sorted more quickly. (and I would ideally like to yank that version but was worried that could cause some issues had been pulled in as a dependency by this repo already before I discovered the problem) As it can only happen when debug assertions are enabled (the overflow results in the intended result so it doesn't cause any issue in release mode) and using the wrapping buffer mode when decompressing it is very unlikely to cause any issues here but I would like to get it sorted just to be safe. ```miniz_oxide``` is used in the standard library (and some tools) via ```backtrace-rs ``` which doesn't use a wrapping buffer, and thus won't trigger this condition. There does however seem like there are some tools that do dependency on ```flate2``` which does use ```miniz_oxide``` decompression using a a wrapping buffer and could in theory trigger it if they are run when compiled with debug assertions enabled. It's kinda unclear what version what tool uses though as several of them specify older versions of flate2 which depended on ```miniz_oxide``` 0.7.x in cargo.toml, and ```miniz_oxide```, and not all have a cargo.lock and due to an older version of ```backtrace``` being in the root Cargo.lock which still depended on ```miniz_oxide``` 0.7.4, so that version is also pulled in alongside the newer version.
…th-fix, r=kobzol Fix profiler_builtins build script to handle full path to profiler lib LLVM_PROFILER_RT_LIB may be set to an absolute path (e.g., in Fedora builds), but `-l` expects a library name, not a path. After rust-lang#138273, this caused builds to fail with a "could not find native static library" error. This patch updates the build script to split the path into directory and filename, using `cargo::rustc-link-search` for the directory and `cargo::rustc-link-lib=+verbatim` for the file. This allows profiler_builtins to correctly link the static library even when an absolute path is provided.
…=tgross35,joboet Use `with_native_path` for Windows Ideally, each platform should use their own native path type internally. This will, for example, allow passing a UTF-16 string directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated wide string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this just does some of the Windows parts. As with the previous Unix PR (rust-lang#138832) this is intended to be merely a refactoring so I've avoided anything that may require more substantial changes.
Move `args` into `std::sys` Move platform definitions of `args` into `std::sys`, as part of rust-lang#117276. cc ``@joboet``
… r=dtolnay Move `select_unpredictable` to the `hint` module There has been considerable discussion in both the ACP (rust-lang/libs-team#468) and tracking issue (rust-lang#133962) about whether the `bool::select_unpredictable` method should be in `core::hint` instead. I believe this is the right move for the following reasons: - The documentation explicitly says that it is a hint, not a codegen guarantee. - `bool` doesn't have a corresponding `select` method, and I don't think we should be adding one. - This shouldn't be something that people reach for with auto-completion unless they specifically understand the interactions with branch prediction. Using conditional moves can easily make code *slower* by preventing the CPU from speculating past the condition due to the data dependency. - Although currently `core::hint` only contains no-ops, this isn't a hard rule (for example `unreachable_unchecked` is a bit of a gray area). The documentation only status that the module contains "hints to compiler that affects how code should be emitted or optimized". This is consistent with what `select_unpredictable` does.
* Update comments to clarify the usage of zero as an indication for default stack size configuration * Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform This change improves clarity and consistency in stack size configuration across platforms. Signed-off-by: Huang Qi <[email protected]>
…enton Rollup of 10 pull requests Successful merges: - rust-lang#138972 (std: Fix build for NuttX targets) - rust-lang#139177 (Use -C target-cpu=z13 on s390x vector test) - rust-lang#139511 (libtest: Pass the test's panic payload as Option instead of Result) - rust-lang#139605 (update ```miniz_oxide``` to 0.8.8) - rust-lang#139618 (compiletest: Make `SUGGESTION` annotations viral) - rust-lang#139677 (Fix profiler_builtins build script to handle full path to profiler lib) - rust-lang#139683 (Use `with_native_path` for Windows) - rust-lang#139710 (Move `args` into `std::sys`) - rust-lang#139721 (End all lines in src/stage0 with trailing newline) - rust-lang#139726 (Move `select_unpredictable` to the `hint` module) r? `@ghost` `@rustbot` modify labels: rollup
According to the docs in `Command::output`: > By default, stdout and stderr are captured (and used to provide the resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing. This was being violated by UEFI which was inheriting stdin by default. While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL. UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin. One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route. Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error. Signed-off-by: Ayush Singh <[email protected]>
Allows implementing Stdio::Null for Command in a deterministic manner. Signed-off-by: Ayush Singh <[email protected]>
Stdio::MakePipe is not supported. For Stdio::Null, return UNSUPPORTED. This is treated as read(0). Additionally, have infinte loop on the notify function to prevent wait_for_key from returning. Signed-off-by: Ayush Singh <[email protected]>
The only differences between these implementations are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix.
…ross35,RalfJung,WaffleLapkin Initial `UnsafePinned` implementation [Part 1: Libs] Initial libs changes necessary to unblock further work on [RFC 3467](https://rust-lang.github.io/rfcs/3467-unsafe-pinned.html). Tracking issue: rust-lang#125735 This PR is split off from rust-lang#136964, and includes just the libs changes: - `UnsafePinned` struct - private `UnsafeUnpin` structural auto trait - Lang items for both - Compiler changes necessary to block niches on `UnsafePinned` This PR does not change codegen, miri, the existing `!Unpin` hack, or anything else. That work is to be split into later PRs. --- cc ``@RalfJung`` ``@Noratrieb`` ``@rustbot`` label F-unsafe_pinned T-libs-api
Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`.
Signed-off-by: xizheyin <[email protected]>
If you want to logically split an iterator after `n` items, you might first discover `take`. Before this change, you'd find that `take` consumes the iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's hard to discover, especially since `by_ref` is a bit abstract and `Iterator` has many methods. After this change, you'd see the example showing `take` along with `by_ref`, which allows you to continue using the rest of the iterator. `by_ref` had a good example involving `take` already, so this change just duplicates that existing example under `take`.
Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
* "while until either" could also be changed to "for a while until either", but I just deleted "while". * fixed sentence with incorrect "at" and "has/have". * linked [*currently allocated*] similar to other methods.
Report line number of test when should_panic test failed Closes rust-lang#137405 --- try-job: x86_64-gnu-llvm-19-3 try-job: test-various
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#139127 (Fix up partial res of segment in primitive resolution hack) - rust-lang#139392 (Detect and provide suggestion for `&raw EXPR`) - rust-lang#139767 (Visit place in `BackwardIncompatibleDropHint` statement) - rust-lang#139777 (Remove `define_debug_via_print` for `ExistentialProjection`, use regular structural debug impl) - rust-lang#139796 (ptr docs: add missing backtics around 'usize') - rust-lang#139801 (Add myself to mailmap) - rust-lang#139804 (use `realpath` in `bootstrap.py` when creating build-dir) - rust-lang#139807 (Improve wording of post-merge report) r? `@ghost` `@rustbot` modify labels: rollup
This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized. Fixes rust-lang#139803
…, r=joboet Avoid unused clones in `Cloned<I>` and `Copied<I>` Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`. r? libs-api
approved in ACP rust-lang/libs-team#554
…ct, r=compiler-errors,oli-obk,RalfJung Enable contracts for const functions Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions. This commit also removes one level of indirection for ensures clauses since we no longer build a closure around the ensures predicate. Resolves rust-lang#136925 **Call-out:** This is still a draft PR since CI is broken due to a new warning message for unreachable code when the bottom of the function is indeed unreachable. It's not clear to me why the warning wasn't triggered before. r? ```@compiler-errors```
…oboet std: sys: process: uefi: Use NULL stdin by default According to the docs in `Command::output`: > By default, stdout and stderr are captured (and used to provide the resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing. This was being violated by UEFI which was inheriting stdin by default. While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL. UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin. One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route. Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error. cc ```@nicholasbishop``` ```@dvdhrm```
…=tgross35 std: add Output::exit_ok approved in ACP rust-lang/libs-team#554 Tracking issue: rust-lang#84908
Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file}
Simplification/redesign of the unstable proc macro span API, tracked in rust-lang#54725:
Before:
```rust
impl Span {
pub fn line(&self) -> usize;
pub fn column(&self) -> usize;
pub fn source_file(&self) -> SourceFile;
}
#[derive(Clone, Debug, PartialEq, Eq)]
pub struct SourceFile { .. }
impl !Send for SourceFile {}
impl !Sync for SourceFile {}
impl SourceFile {
pub fn path(&self) -> PathBuf;
pub fn is_real(&self) -> bool;
}
```
After:
```rust
impl Span {
pub fn line(&self) -> usize;
pub fn column(&self) -> usize;
pub fn file(&self) -> String; // Mapped file name, for display purposes.
pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on disk.
}
```
This resolves the last blocker for stabilizing these methods. (Stabilizing will be a separate PR with FCP.)
… r=fee1-dead
Clean up "const" situation in format_args!().
This cleans up the "const" situation in the format_args!() expansion/lowering.
Rather than marking the Argument::new_display etc. functions as non-const, this marks the Arguments::new_v1 functions as non-const.
Example expansion/lowering of format_args!() in const:
```rust
// Error: cannot call non-const formatting macro in constant functions
const {
fmt::Arguments::new_v1( // Now the error is produced here.
&["Hello, ", "!\n"],
&[
fmt::Argument::new_display(&world) // The error used to be produced here.
],
)
}
```
Delegate from `std::env::ArgsOs` to the methods of the inner platform-specific iterators, when it would be more efficient than just using the default methods of its own impl. Most platforms use `vec::IntoIter` as the inner type, so prioritize delegating to the methods it provides. `std::env::Args` is implemented atop `std::env::ArgsOs` and performs UTF-8 validation with a panic for invalid data. This is a visible effect which users certainly rely on, so we can't skip any arguments. Any further iterator methods would skip some elements, so no change is needed for that type. Add `#[inline]` for any methods which simply wrap the inner iterator.
These methods now return Result<(), TryLockError> instead of Result<bool, Error> to make their use less errorprone
…heemdev std: use the address of `errno` to identify threads in `unique_thread_exit` Getting the address of `errno` should be just as cheap as `pthread_self()` and avoids having to use the expensive `Mutex` logic because it always results in a pointer.
…s, r=ibraheemdev Clarify `async` block behaviour Adds some documentation for control flow behaviour pertaining to `return` and `?` within `async` blocks. Fixes (or at least improves) rust-lang#101444. r? rust-lang/docs
…workingjubilee Delegate to inner `vec::IntoIter` from `env::ArgsOs` Delegate from `std::env::ArgsOs` to the methods of the inner platform-specific iterators, when it would be more efficient than just using the default methods of its own impl. Most platforms use `vec::IntoIter` as the inner type, so prioritize delegating to the methods it provides. `std::env::Args` is implemented atop `std::env::ArgsOs` and performs UTF-8 validation with a panic for invalid data. This is a visible effect which users certainly rely on, so we can't skip any arguments. Any further iterator methods would skip some elements, so no change is needed for that type. Add `#[inline]` for any methods which simply wrap the inner iterator.
…orkingjubilee Avoid redundant WTF-8 checks in `PathBuf` Eliminate checks for WTF-8 boundaries in `PathBuf::set_extension` and `add_extension`, where joining WTF-8 surrogate halves is impossible. Don't convert the `str` to `OsStr`, because `OsString::push` specializes to skip the joining when given strings. To assist in this, mark the internal methods `OsString::truncate` and `extend_from_slice` as `unsafe` to communicate their safety invariants better than with module privacy. Similar to rust-lang#137777. cc `@joboet` `@ChrisDenton`
Document breaking out of a named code block Closes rust-lang#110758.
Remove `avx512dq` and `avx512vl` implication for `avx512fp16` According to Intel, `avx512fp16` requires only `avx512bw`, but LLVM also enables `avx512vl` and `avx512dq` when `avx512fp16` is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512 Related: - llvm/llvm-project#136209 - rust-lang#138940 - rust-lang/stdarch#1781 - rust-lang#111137 ``@rustbot`` label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs r? ``@Amanieu`` **Update: the LLVM fix has been merged** cc ``@rust-lang/wg-llvm`` will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
…=Amanieu Rename `*Guard::try_map` to `filter_map`. Rename `std::sync::*Guard::try_map` to `filter_map`. 1. Analogous to `std::cell::Ref(Mut)::filter_map`. 2. Doesn't imply `Try` genericizability. r? `@Amanieu` (or other T-libs-api) Tracking issue for `mapped_lock_guards`: rust-lang#117108
…able, r=workingjubilee Stabilize `select_unpredictable` FCP completed in tracking issue rust-lang#133962.
…kingjubilee Change signature of File::try_lock and File::try_lock_shared These methods now return Result<(), TryLockError> instead of Result<bool, Error> to make their use less errorprone These methods are unstable under the "file_lock" feature. The related tracking issue is rust-lang#130999 and this PR changes the signatures as discussed by libs-api: rust-lang#130994 (comment)
…in-std-io-pipe-docs, r=tgross35 Use present indicative tense in std::io::pipe() API docs The inline documentation for all other free functions in the `std::io` module use the phrase "creates a" instead of "create a", except for the currently nightly-only `std::io::pipe()` function. This commit updates the text to align with the predominant wording in the `std::io` module. I recognize this PR is quite a minuscule nitpick, so feel free to ignore and close if you disagree and/or there are bigger fish to fry. Thanks in advance! :smile: Relates to rust-lang#127154.
…ypo, r=cuviper doc(std): fix typo lchown -> lchmod chown is irrelevant here, as this function does not affect file ownership. chmod is the correct function to reference here.
tautschnig
approved these changes
May 11, 2025
|
I expect we need #346 to be merged before all CI jobs pass on this one. |
We also need to add |
|
This PR doesn't appear to update the So we'll need to update that submodule, as well as investigate whether our current automation approach just doesn't handle submodule updates, or if there was something funky about this particular one. (I thought I remembered a previous update with submodule changes where the automation went through fine...) |
Did the update to our |
Yes. When I open the submodule folders for |
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-06 (rust-lang/rust@2e6882a) (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: 794e274