Merge subtree update for toolchain nightly-2025-06-03 #380
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}
… 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
The previous commit moved all test files from `std` to `core` so git understands the move. Not all functionality is actually testable in `core`, however, so perform move the relevant portions back. Changes from inherent to module methods is also done since this is the form of math operations available in `core` (as `core_float_math`).
Per [1], MinGW has an incorrect fma implementation. This showed up in tests run with cranelift after adding float math operations to `core`. Presumably we hadn't noticed this when running tests with LLVM because LLVM was constant folding the result away. Rust issue: rust-lang#140515 [1]: https://sourceforge.net/p/mingw-w64/bugs/848/
…, r=tgross35 MaybeUninit::write: fix doc # Fix doc for `MaybeUninit::write` The documentation refers to the way `MaybeUninit` stores data internally. The property of not dropping content on context exit is the responsibility of `ManuallyDrop`.
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
`equialent` => `equivalent`
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
…Void Fix typo in `StructuralPartialEq` docs `equialent` => `equivalent`
add f16_epsilon and f128_epsilon diagnostic items cc rust-lang#116909 r? ``@tgross35``
|
Requires #386 to be merged first. |
|
The I suspect because the newest Kani version enables the verify-rust-std/library/core/src/slice/ascii.rs Lines 470 to 472 in 0840b22 instead of this one, where the loop invariant is: verify-rust-std/library/core/src/slice/ascii.rs Lines 363 to 366 in 0840b22 @thanhnguyen-aws can you add a loop invariant to the other function so that the proof passes again? |
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-02 (rust-lang/rust@99e7c15) to 2025-06-03 (rust-lang/rust@5d707b0), inclusive. This is a clean merge, no conflicts were detected. Do not remove or edit the following annotations:
git-subtree-dir: library
git-subtree-split: 018adbd