Merge subtree update for toolchain nightly-2025-06-18 #398
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}
The rounding tests are now supported, so there is no longer any reason to skip these.
`assert_eq!` ignores the sign of zero, but for any tests involving zeros we do care about this sign. Replace `assert_eq!` with `assert_biteq!` everywhere possible for float tests to ensure we don't miss this. `assert_biteq!` is also updated to check equality on non-NaNs, to catch the unlikely case that bitwise equality works but our `==` implementation is broken. There is one notable output change: we were asserting that `(-0.0).fract()` and `(-1.0).fract()` both return -0.0, but both actually return +0.0.
We don't actually need this for now, but eventually it would be nice to run icount benchmarks on multiple targets. Start tagging artifact names with the architecture, and allow passing `--tag` to `ci-util.py` in order to retrieve the correct one.
…llaumeGomez Rollup of 11 pull requests Successful merges: - rust-lang#137574 (Make `std/src/num` mirror `core/src/num`) - rust-lang#141384 (Enable review queue tracking) - rust-lang#141448 (A variety of improvements to the codegen backends) - rust-lang#141636 (avoid some usages of `&mut P<T>` in AST visitors) - rust-lang#141676 (float: Disable `total_cmp` sNaN tests for `f16`) - rust-lang#141705 (Add eslint as part of `tidy` run) - rust-lang#141715 (Add `loongarch64` with `d` feature to `f32::midpoint` fast path) - rust-lang#141723 (Provide secrets to try builds with new bors) - rust-lang#141728 (Fix false documentation of FnCtxt::diverges) - rust-lang#141729 (resolve target-libdir directly from rustc) - rust-lang#141732 (creader: Remove extraenous String::clone) r? `@ghost` `@rustbot` modify labels: rollup
atomic_load intrinsic: use const generic parameter for ordering We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that! This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics. The first two commits are preparation and could be a separate PR if you prefer. `@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer... `@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
…fJung float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: rust-lang#138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu try-job: x86_64-gnu-aux
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
Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if` This new parameter was requested in the btree_extract_if tracking issue: rust-lang#70530 (comment) I attempted to follow the style used by `Vec::extract_if`. Before: ```rust impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> { #[unstable(feature = "btree_extract_if", issue = "70530")] pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A> where K: Ord, F: FnMut(&K, &mut V) -> bool; } ``` After: ```rust impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> { #[unstable(feature = "btree_extract_if", issue = "70530")] pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A> where K: Ord, R: RangeBounds<K>, F: FnMut(&K, &mut V) -> bool; } ``` Related: rust-lang#70530 — While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
…ngjubilee Implement ((un)checked_)exact_div methods for integers tracking issue: rust-lang#139911 I see that there might still be some bikeshedding to be done, so if people want changes to this implementation, I'm happy to make those. I did also see that there was a previous attempt at this PR (rust-lang#116632), but I'm not sure why it got closed.
…39190, r=workingjubilee core: begin deduplicating pointer docs this also cleans up two inconsistancies: 1. both doctests on the ::add methods were actually calling the const version. 2. on of the ::offset methods was missing a line of clarification. part of rust-lang#139190
This commit improves the Clone trait documentation to address confusion around what "duplication" means for different types, especially for smart pointers like Arc<Mutex<T>>. Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Revert "increase perf of charsearcher for single ascii characters" This reverts commit 245bf50 (PR rust-lang#141516). It caused a large `doc` perf. regression in rust-lang#141605.
…<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
…lexcrichton Remove wasm legacy abi Closes rust-lang#122532 Closes rust-lang#138762 Fixes rust-lang#71871 rust-lang#88152 Fixes rust-lang#115666 Fixes rust-lang#129486
Pick up the following pull requests: * ci: remove binary size check (not relevant in rust-lang/rust) <rust-lang/backtrace-rs#710> * Upgrade `ruzstd`, `object`, and `addr2line` to the latest versions <rust-lang/backtrace-rs#718>
…enton Stabilize "file_lock" feature Closes rust-lang#130994 r? ```@joshtriplett```
…cs, r=tgross35 Add documentation for `PathBuf`'s `FromIterator` and `Extend` impls I think it's not very obvious that `PathBuf`'s `Extend` and `FromIterator` impls work like `PathBuf::push`, so I think these should be documented. I'm not very happy with the wording and examples, open to suggestions :)
…ss35 Fix Debug for Location Fixes rust-lang#142279
Introduce the `MetaSized` and `PointeeSized` traits as supertraits of `Sized` and initially implement it on everything that currently implements `Sized` to isolate any changes that simply adding the traits introduces.
more information to Display implementation for BorrowError/BorrowMutError - The BorrowError/BorrowMutError Debug implementations do not print anything differently from what the derived implementation does, so we don't need it. - This change also adds the location field of BorrowError/BorrowMutError to the the Display output when it is present, rewords the error message, and uses the Display trait for outputting the error message instead of Debug.
It's actually used as a counter so update the name to reflect that.
…ngjubilee Update the `backtrace` submodule Pick up the following pull requests: * ci: remove binary size check (not relevant in rust-lang/rust) <rust-lang/backtrace-rs#710> * Upgrade `ruzstd`, `object`, and `addr2line` to the latest versions <rust-lang/backtrace-rs#718>
As core uses an extern type (`ptr::VTable`), the default `?Sized` to `MetaSized` migration isn't sufficient, and some code that previously accepted `VTable` needs relaxed to continue to accept extern types. Similarly, the compiler uses many extern types in `rustc_codegen_llvm` and in the `rustc_middle::ty::List` implementation (`OpaqueListContents`) some bounds must be relaxed to continue to accept these types. Unfortunately, due to the current inability to relax `Deref::Target`, some of the bounds in the standard library are forced to be stricter than they ideally would be.
Adding a sizedness supertrait shouldn't require multiple vtables so shouldn't be linted against.
Make performance description of String::{insert,insert_str,remove} more precise
std: refactor explanation of `NonNull` Fixes rust-lang#141933 I cut out the excessive explanation and used an example to explain how to maintain invariance, but I think what is quoted in the *rust reference* in the document needs to be added with a more layman's explanation and example. (I'm not sure if I deleted too much) r? `@workingjubilee`
Miscellaneous RefCell cleanups - Clarify `RefCell` error messages when borrow rules are broken - Remove `Debug` impl for `BorrowError`/`BorrowMutError` since `#derive(Debug)` provides identical functionality - Rename `BorrowFlag` to `BorrowCounter`
Sized Hierarchy: Part I This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract. These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler. RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - `?Sized` is rewritten as `MetaSized` - `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. There are no edition migrations implemented in this, as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled. Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately). It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output. **Notes:** - Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged. - This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together. - Each commit has a short description describing its purpose. - This patch is large but it's primarily in the test suite. - I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor. - `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway. - `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491) - FCP in rust-lang#137944 (comment) Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
…kingjubilee Rollup of 13 pull requests Successful merges: - rust-lang#138538 (Make performance description of String::{insert,insert_str,remove} more precise) - rust-lang#141946 (std: refactor explanation of `NonNull`) - rust-lang#142216 (Miscellaneous RefCell cleanups) - rust-lang#142542 (Manually invalidate caches in SimplifyCfg.) - rust-lang#142563 (Refine run-make test ignores due to unpredictable `i686-pc-windows-gnu` unwind mechanism) - rust-lang#142570 (Reject union default field values) - rust-lang#142584 (Handle same-crate macro for borrowck semicolon suggestion) - rust-lang#142585 (Update books) - rust-lang#142586 (Fold unnecessary `visit_struct_field_def` in AstValidator) - rust-lang#142587 (Make sure to propagate result from `visit_expr_fields`) - rust-lang#142595 (Revert overeager warning for misuse of `--print native-static-libs`) - rust-lang#142598 (Set elf e_flags on ppc64 targets according to abi) - rust-lang#142601 (Add a comment to `FORMAT_VERSION`.) r? `@ghost` `@rustbot` modify labels: rollup
tautschnig
previously approved these changes
Jun 27, 2025
tautschnig
dismissed
their stale review
We need to rework some of the contracts.
|
Requires Kani fix model-checking/kani#4193 to be merged first. |
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-06-17 (rust-lang/rust@45acf54) to 2025-06-18 (rust-lang/rust@f3db639) (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: a46ec5c