Merge subtree update for toolchain nightly-2025-06-02 #378
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}
[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 <post@ralfj.de>
…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
The output of Array::map is intended to be an array of the same size, and does not modify the original in place nor is it intended for side-effects. Thus, under normal circumstances it should be consumed. See [discussion](https://internals.rust-lang.org/t/array-map-annotate-with-must-use/22813/26). Attaching to tracking issue rust-lang#75243
Since [1], `compiler-builtins` makes a certain set of math symbols weakly available on all platforms. This means we can begin exposing some of the related functions in `core`, so begin this process here. It is not possible to provide inherent methods in both `core` and `std` while giving them different stability gates, so standalone functions are added instead. This provides a way to experiment with the functionality while unstable; once it is time to stabilize, they can be converted to inherent. For `f16` and `f128`, everything is unstable so we can move the inherent methods. The following are included to start: * floor * ceil * round * round_ties_even * trunc * fract * mul_add * div_euclid * rem_euclid * powi * sqrt * abs_sub * cbrt These mirror the set of functions that we have in `compiler-builtins` since [1]. Tracking issue: rust-lang#137578 [1]: rust-lang/compiler-builtins#763
Many float-related tests in `std` only depend on `core`, so move the tests there. This also allows us to verify functions from `core_float_math`. Since the majority of test files need to be moved to `coretests`, move the files here without any cleanup; this is done in a followup commit. This makes git history slightly cleaner, but coretests will not build immediately after this commit.
They will be used in Clippy to detect runtime parsing of known-valid IP addresses.
…SK_RENAME_LENGTH-1
…<str>::from_utf8*` methods Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Do not move thread-locals before dropping Fixes rust-lang#140816. I also (potentially) improved the speed of `get_or_init` a bit by having an explicit hot/cold path. We still move the value before dropping in the event of a recursive initialization (leading to double-initialization with one value being silently dropped). This is the old behavior, but changing this to panic instead would involve changing tests and also the other OS-specific `thread_local/os.rs` implementation, which is more than I'd like in this PR.
…lacrum std: note that `std::str::from_utf8*` functions are aliases to `<str>::from_utf8*` methods Closes rust-lang#141079 r? libs
Update `compiler-builtins` to 0.1.160 Includes the following changes: * Enable `__powitf2` on MSVC [1] * Update `CmpResult` to use a pointer-sized return type [2] * Better code reuse between `libm` and `compiler-builtins` [3], [4] * Stop building C versions of `__netf2` [5] since we have our own implementation [1]: rust-lang/compiler-builtins#918 [2]: rust-lang/compiler-builtins#920 [3]: rust-lang/compiler-builtins#879 [4]: rust-lang/compiler-builtins#925 [5]: rust-lang/compiler-builtins#828
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#140787 (Note expr being cast when encounter NonScalar cast error) - rust-lang#141112 (std: note that `std::str::from_utf8*` functions are aliases to `<str>::from_utf8*` methods) - rust-lang#141646 (Document what `distcheck` is intended to exercise) - rust-lang#141740 (Hir item kind field order) - rust-lang#141793 (`tests/ui`: A New Order [1/N]) - rust-lang#141805 (Update `compiler-builtins` to 0.1.160) - rust-lang#141815 (Enable non-leaf Frame Pointers for mingw-w64 Arm64 Windows) - rust-lang#141819 (Fixes for building windows-gnullvm hosts) r? `@ghost` `@rustbot` modify labels: rollup
Add const support for the float rounding methods floor, ceil, trunc,
fract, round and round_ties_even.
This works by moving the calculation logic from
src/tools/miri/src/intrinsics/mod.rs
into
compiler/rustc_const_eval/src/interpret/intrinsics.rs.
All relevant method definitions were adjusted to include the `const`
keyword for all supported float types: f16, f32, f64 and f128.
The constness is hidden behind the feature gate
feature(const_float_round_methods)
which is tracked in
rust-lang#141555
This commit is a squash of the following commits:
- test: add tests that we expect to pass when float rounding becomes const
- feat: make float rounding methods `const`
- fix: replace `rustc_allow_const_fn_unstable(core_intrinsics)` attribute with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
- revert: undo update to `library/stdarch`
- refactor: replace multiple `float_<mode>_intrinsic` rounding methods with a single, parametrized one
- fix: add `#[cfg(not(bootstrap))]` to new const method tests
- test: add extra sign tests to check `+0.0` and `-0.0`
- revert: undo accidental changes to `round` docs
- fix: gate `const` float round method behind `const_float_round_methods`
- fix: remove unnecessary `#![feature(const_float_methods)]`
- fix: remove unnecessary `#![feature(const_float_methods)]` [2]
- revert: undo changes to `tests/ui/consts/const-eval/float_methods.rs`
- fix: adjust after rebase
- test: fix float tests
- test: add tests for `fract`
- chore: add commented-out `const_float_round_methods` feature gates to `f16` and `f128`
- fix: adjust NaN when rounding floats
- chore: add FIXME comment for de-duplicating float tests
- test: remove unnecessary test file `tests/ui/consts/const-eval/float_methods.rs`
- test: fix tests after upstream simplification of how float tests are run
In the previous description it said there was a TOCTOU race but did not explain exactly what the problem was. I sat down with the CVE, reviewed its text, and created this explanation. This context should hopefully help people understand the actual risk as-such. Incidentally, it also fixes the capitalization on the name of Redox OS.
…ic, r=workingjubilee `slice.get(i)` should use a slice projection in MIR, like `slice[i]` does `slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds. This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement. (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.) I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition. Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata. But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`. Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward. Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
…atten, r=jhpratt Stabilize feature `result_flattening` Stabilizes the `Result::flatten` method ## Implementations - [x] Implementation `Result::flatten`: rust-lang#70140 - [x] Implementation `const` `Result::flatten`: rust-lang#130692 - [x] Update stabilization attribute macros (this PR) ## Stabilization process - [x] Created this PR [suggested](rust-lang#70142 (comment)) by ``@RalfJung`` - [x] FCP (haven't found any, is it applicable here?) - [ ] Close issue rust-lang#70142
…bilee std: clarify Clone trait documentation about duplication semantics Closes rust-lang#141138 The change explicitly explains that cloning behavior varies by type and clarifies that smart pointers (`Arc`, `Rc`) share the same underlying data. I've also added an example of cloning to Arc.
…r=RalfJung
Add `const` support for float rounding methods
# Add `const` support for float rounding methods
This PR makes the following float rounding methods `const`:
- `f64::{floor, ceil, trunc, round, round_ties_even}`
- and the corresponding methods for `f16`, `f32` and `f128`
Tracking issue: rust-lang#141555
## Procedure
I followed rust-lang@c09ed3e as closely as I could in making float methods `const`, and also received great guidance from https://internals.rust-lang.org/t/const-rounding-methods-in-float-types/22957/3?u=ruancomelli.
## Note
This is my first code contribution to the Rust project, so please let me know if I missed anything - I'd be more than happy to revise and learn more. Thank you for taking the time to review it!
…-races-are, r=thomcc,ChrisDenton library: explain TOCTOU races in `fs::remove_dir_all` In the previous description it said there was a TOCTOU race but did not explain exactly what the problem was. I sat down with the CVE, reviewed its text, and created this explanation. This context should hopefully help people understand the actual risk as-such. Incidentally, it also fixes the capitalization on the name of Redox OS. Original CVE and advisory: - CVE: https://www.cve.org/CVERecord?id=CVE-2022-21658 - security advisory: https://groups.google.com/g/rustlang-security-announcements/c/R1fZFDhnJVQ?pli=1 - github cross-post: GHSA-r9cc-f5pr-p3j2
Rollup of 6 pull requests Successful merges: - rust-lang#141072 (Stabilize feature `result_flattening`) - rust-lang#141215 (std: clarify Clone trait documentation about duplication semantics) - rust-lang#141277 (Miri CI: test aarch64-apple-darwin in PRs instead of the x86_64 target) - rust-lang#141521 (Add `const` support for float rounding methods) - rust-lang#141812 (Fix "consider borrowing" for else-if) - rust-lang#141832 (library: explain TOCTOU races in `fs::remove_dir_all`) r? `@ghost` `@rustbot` modify labels: rollup
terminology: allocated object → allocation Rust does not have "objects" in memory so "allocated object" is a somewhat odd name. I am not sure where the term comes from. "object" has been used to refer to allocations already [in 1.0 docs](https://doc.rust-lang.org/1.0.0/std/primitive.pointer.html#method.offset); this was apparently later changed to "allocated object". "Allocation" is already the terminology used in Miri and in the [UCG](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#allocation). We should properly move to that terminology, and avoid any confusion about whether Rust has an object memory model. (It does not. Memory contains untyped bytes.) Cc ``@rust-lang/opsem`` ``@rust-lang/lang``
…llaumeGomez Rollup of 9 pull requests Successful merges: - rust-lang#140370 (Improve diagnostics for usage of qualified paths within tuple struct exprs/pats) - rust-lang#141224 (terminology: allocated object → allocation) - rust-lang#141622 (implement `va_arg` for `powerpc`) - rust-lang#141666 (source_span_for_markdown_range: fix utf8 violation) - rust-lang#141789 (Exclude `CARGO_HOME` from `generate-copyright` in-tree determination) - rust-lang#141823 (Drive-by refactor: use `OnceCell` for the reverse region SCC graph) - rust-lang#141834 (Add unimplemented `current_dll_path()` for WASI) - rust-lang#141846 (Fix TLS model on bootstrap for cygwin) - rust-lang#141852 (resolve if-let-chain FIXME on bootstrap) r? `@ghost` `@rustbot` modify labels: rollup
tautschnig
approved these changes
Jun 3, 2025
carolynzech
approved these changes
Jun 4, 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-05-28 (rust-lang/rust@45f256d) to 2025-06-02 (rust-lang/rust@99e7c15) (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: 513fc8f