forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 0
Update subtree/library to 2025-06-16 #42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
github-actions
wants to merge
10,000
commits into
subtree/library
Choose a base branch
from
update-subtree/library
base: subtree/library
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
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
clean up old rintf leftovers As usual stdarch needed special treatment due to rust-lang/stdarch#1655, and apparently I forgot to clean up these leftovers here. They can be removed now.
Call out possibility of invariant result in variance markers ref rust-lang#135806 (comment)
…r=bjorn3 core: unstably expose atomic_compare_exchange so stdarch can use it Due to rust-lang/stdarch#1655, cleaning up the atomic intrinsics will be a bunch of extra work: stdarch directly calls them [here](https://github.com/rust-lang/stdarch/blob/8764244589373b8b48864c0ad11fd9233c672249/crates/core_arch/src/x86_64/cmpxchg16b.rs#L58-L74). Instead of duplicating that match, stdarch should use what we have in libcore, so let's expose that. r? `@bjorn3`
Add `rustc_diagnostic_item` to `sys::Mutex` methods For an ongoing project for adding a concurrency model checker to Miri we need to be able to intercept locking/unlocking operations on standard library mutexes. This PR adds diagnostic items to the relevant calls `lock`, `try_lock` and `unlock` for the `sys::Mutex` implementation on the targets we care about. This PR also makes the internals of `pthread::Mutex` less public, to reduce the chance of anyone locking/unlocking a mutex without going through the intercepted methods. r? ``@RalfJung``
add `CStr::display` The implementation delegates to `<ByteStr as Display>::fmt`. Link: rust-lang/libs-team#550 Link: rust-lang#139984. r? ```@BurntSushi``` cc ```@Darksonn``` ```@tgross35``` ```@ojeda``` ```@joshtriplett```
coretests: extend and simplify float tests Also de-duplicate tests by removing a ui test that duplicates the tests in core. r? `@tgross35`
Since the two crates are now in the same repo, it is easier to share code. Begin some deduplication with the integer traits.
Rollup of 4 pull requests Successful merges: - rust-lang#138285 (Stabilize `repr128`) - rust-lang#139994 (add `CStr::display`) - rust-lang#141571 (coretests: extend and simplify float tests) - rust-lang#141656 (CI: Add cargo tests to aarch64-apple-darwin) Failed merges: - rust-lang#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`) - rust-lang#141636 (avoid some usages of `&mut P<T>` in AST visitors) r? `@ghost` `@rustbot` modify labels: rollup
…r=onur-ozkan Do not get proc_macro from the sysroot in rustc With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work. To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case: * Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at rust-lang#116672. * LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version). * Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at rust-lang#132422, rust-lang#132741, rust-lang#134115. * LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783. * Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at rust-lang#134290. At [3], the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version. `repr(i128)` was added to this lint in [4], but is also removed here. Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches. Closes: rust-lang#134288 Closes: rust-lang#128950 [1]: rust-lang#54341 [2]: rust-lang#128950 [3]: rust-lang/lang-team#255 (comment) [4]: rust-lang#138282
The float modules in `std` are currently top-level but for `core`, they are nested within the `num` directory and referenced by `#[path = ...]`. For consistency, adjust `std` to use the same structure as `core`. Also change the `f16` and `f128` gates from outer attributes to inner attributes like `core` has.
…workingjubilee float: Disable `total_cmp` sNaN tests for `f16` There is an LLVM bug with lowering of basic `f16` operations that mean a round trip via `__extendhfsf2` and `__truncsfhf2` may happen for simple `abs` calls or bitcasts [1]. This is problematic because the round trip quiets signaling NaNs. For most operations this is acceptable, but it is causing `total_cmp` tests to fail unless optimizations are enabled. Disable `total_cmp` tests involving signaling NaNs until this issue is resolved. Fixes: rust-lang/rustc_codegen_cranelift#1578 Fixes: rust-lang#141503 [1]: llvm/llvm-project#104915
…8472 Add `loongarch64` with `d` feature to `f32::midpoint` fast path This patch enables the optimized implementation of `f32::midpoint` for `loongarch64` targets that support the `d`feature. Targets with reliable 64-bit float support can safely use the faster and more accurate computation via `f64`, avoiding the fallback branchy version.
These are now provided by `compiler-builtins`, so there is no need to also build the C versions. This was detected by checking for duplicate symbols and not excluding weak symbols (like CI currently does).
This should be less error-prone and adaptable than the `nm` version, and have better cross-platform support without needing LLVM `nm` installed.
Since a working `nm` is no longer needed as part of CI, the rustup component can be removed.
Do the same for `builtins-test-intrinsics`. Mostly this means updating `extern` to `unsafe extern`, and fixing a few new Clippy lints.
As part of this, the u256 benchmarks are reorganized to a group.
Currently we only build this, but it is possible to run the binary. Change the CI script to do so here.
When multiple merges to `master` happen before a CI run completes, the in-progress job is getting canceled. Fix this by using the commit sha for the group key if a pull request number is not available, rather than `github.ref` (which is always `refs/head/master` after merge). This should prevent jobs running on previous commits from getting cancelled, while still ensuring there is only ever one active run per pull request.
We may soon want to use some new nightly features in `compiler-builtins` and `libm`, specifically `cfg_target_has_reliable_f16_f128` which was added in the past few weeks. This will mean we need a newer toolchain for benchmarks to continue building. Bump to the current latest nightly so we are not blocked on this down the line.
Currently we run logspace tests for extensive tests, but there isn't any reason we couldn't also run more kinds of tests more extensively (e.g. more edge cases, combine edge cases with logspace for multi-input functions, etc). As a first step toward making this possible, make `extensive` a new field in `CheckCtx`, and rename `QuickSpaced` to `Spaced`.
Clean up the separate `assert_f{16,32,64,128}` macros with a single `assert_biteq!` macro that works for all float widths.
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 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.
…lett Delegate `<CStr as Debug>` to `ByteStr` This allows UTF-8 characters to be printed without escapes, rather than just ASCII. r? `@joshtriplett`
Tracking the old name of renamed unstable library features This PR resolves the first problem of rust-lang#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification. r? `@jdonszelmann` There have been a lot of PR's reviewed by you lately, thanks for your time! cc `@jyn514`
…workingjubilee intrinsics: rename min_align_of to align_of Now that `pref_align_of` is gone (rust-lang#141803), we can give the intrinsic backing `align_of` its proper name. r? `@workingjubilee` or `@bjorn3`
Update the stdarch submodule Includes the following changes: * Add s390x z17 target features [1] * Remove `compiler-builtins` from `rustc-dep-of-std` dependencies [2] * Darwin AArch64 detection update [3] * Fixes for the latest nightly [4] * Add a lockfile [5] [1]: rust-lang/stdarch#1826 [2]: rust-lang/stdarch#1825 [3]: rust-lang/stdarch#1827 [4]: rust-lang/stdarch#1830 [5]: rust-lang/stdarch#1829
…r=Mark-Simulacrum Update dependencies in `library/Cargo.lock` This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1]. [1]: rust-lang#142265
…=Mark-Simulacrum Upgrade `object`, `addr2line`, and `unwinding` in the standard library Object: 0.37.0 is a semver-breaking release but the only breakage is in `elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld. This API is not used by `std`, so we should be fine to upgrade. This new version also includes functionality for parsing Wasm object files that we may eventually like to make use of. Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370 Addr2line: 0.25.0 is a breaking change only because it upgrades the `gimli` version. It also includes a change to the `compiler-builtins` dependency that helps with [1]. Changelog: https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md#0250-20250611 [1]: rust-lang#142265
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#138016 (Added `Clone` implementation for `ChunkBy`) - rust-lang#141162 (refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking) - rust-lang#141474 (Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints) - rust-lang#141947 (Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field.) - rust-lang#142252 (Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations) - rust-lang#142337 (miri: add flag to suppress float non-determinism) r? `@ghost` `@rustbot` modify labels: rollup
Replace `build.rs` Rust generation with macros, using the unstable `${concat(...)}`. Fixes: rust-lang/compiler-builtins#947
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#134847 (Implement asymmetrical precedence for closures and jumps) - rust-lang#141491 (Delegate `<CStr as Debug>` to `ByteStr`) - rust-lang#141770 (Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code) - rust-lang#142069 (Introduce `-Zmacro-stats`) - rust-lang#142158 (Tracking the old name of renamed unstable library features) - rust-lang#142221 ([AIX] strip underlying xcoff object) - rust-lang#142340 (miri: we can use apfloat's mul_add now) - rust-lang#142379 (Add bootstrap option to compile a tool with features) - rust-lang#142410 (intrinsics: rename min_align_of to align_of) - rust-lang#142413 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Intrinsic functions declared in `std::intrinsics` are an implementation detail and should not be called directly by the user. The compiler explicitly warns against their use in user code: ``` warning: the feature `core_intrinsics` is internal to the compiler or standard library --> src/lib.rs:1:12 | 1 | #![feature(core_intrinsics)] | ^^^^^^^^^^^^^^^ | = note: using it is strongly discouraged = note: `#[warn(internal_features)]` on by default ``` [**Playground link**] This PR documents what the compiler warning says: these intrinsics should not be called outside the standard library. [**Playground link**]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1c893b0698291f550bbdde0151fd221b
After adding tests, the current implementation for fminimum fails when provided a negative zero and NaN as inputs: ---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64 stdout ---- thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13: fmaximum_num(-0x0p+0, NaN) l: NaN (0x7ff8000000000000) r: -0.0 (0x8000000000000000) ---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32 stdout ---- thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13: fmaximum_num(-0x0p+0, NaN) l: NaN (0x7fc00000) r: -0.0 (0x80000000) Add more thorough spec tests for these functions and correct the implementations. Canonicalization is also moved to a trait method to centralize documentation about what it does and doesn't do.
Use a consistent ordering for top-level manifest keys, and remove those that are now redundant (`homapage` isn't supposed to be the same as `repository`, and `documentation` automatically points to docs.rs now).
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang#140770 (add `extern "custom"` functions) - rust-lang#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang#142248 (Add supported asm types for LoongArch32) - rust-lang#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang#142274 (Update the stdarch submodule) - rust-lang#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang#140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various
Now that this repository is a subtree, we have no need to continue publishing `compiler-builtins`.
The config file is not needed anymore since compiler-builtins is no longer published. Removing it will resolve a CI failure.
…viper add Vec::peek_mut Tracking issue: rust-lang#122742
…r=RalfJung doc: mention that intrinsics should not be called in user code Intrinsic functions declared in `std::intrinsics` are an implementation detail and should not be called directly by the user. The compiler explicitly warns against their use in user code: ``` warning: the feature `core_intrinsics` is internal to the compiler or standard library --> src/lib.rs:1:12 | 1 | #![feature(core_intrinsics)] | ^^^^^^^^^^^^^^^ | = note: using it is strongly discouraged = note: `#[warn(internal_features)]` on by default ``` [**Playground link**] This PR documents what the compiler warning says: these intrinsics should not be used in user code. [**Playground link**]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1c893b0698291f550bbdde0151fd221b
Remove "intermittent" wording from `ReadDir` `ReadDir` claims that `next` will return an error "if there’s some sort of intermittent IO error during iteration". I'm really not sure what this was intended to mean but the implementations will simply return all OS errors encountered during iteration to the user. What else can they do? This is technically a change in the documented API but seeing as how it doesn't bear any relationship with the implementation I don't think it needs a libs-api fcp.
To prepare for merging from rust-lang/rust, set the version file to: d087f11 Auto merge of rust-lang#134841 - estebank:serde-attr-4, r=wesleywiser
…ub.com/rust-lang/rust Pull recent changes from rust-lang/rust via Josh. Upstream ref: d087f11 Filtered ref: 2d43ce8ac022170e5383f7e5a188b55564b6566a
Out-of-tree testing is broken with the most recent update from rust-lang/rust because it makes `compiler-builtins` depend on `core` by path, which isn't usually available. In order to enable testing outside of rust-lang/rust, add a new crate `builtins-shim` that uses the same source as `compiler-builtins` but drops the `core` dependency. This has replaced `compiler-builtins` as the workspace member and entrypoint for tests.
…riplett Delegate `<SocketAddr as Debug>` to `ByteStr` This allows UTF-8 characters to be printed without escapes, rather than just ASCII. r? ``@joshtriplett``
Unimplement unsized_locals Implements rust-lang/compiler-team#630 Tracking issue here: rust-lang#111942 Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`. There may be more that should be removed (possibly in follow up prs) - the `forget_unsized` function and `forget` intrinsic. - the `unsized_locals` test directory; I've just fixed up the tests for now - various codegen support for unsized values and allocas cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3`` ``@rustbot`` label F-unsized_locals Fixes rust-lang#79409
float tests: deduplicate min, max, and rounding tests Part of rust-lang#141726 Best reviewed commit-by-commit. - Use `assert_biteq!` in the `mod.rs` tests. This requires some trickery to make shadowing macros with imports work. - The min, max, minimum, maximum tests in `tests/floats/f*.rs` are entirely subsumed by what we already have in `tests/float/mod.rs`, so I just removed them. - The rounding tests (floor etc) in `f*.rs` had more test points, so I copied them over. They didn't have `0.5` and `-0.5` though which seem like interesting points in particular regarding the sign of the resulting zero if that's what it sounds to, and they didn't max min/max/inf/nan tests, so this was really a merger of both tests. r? ``@tgross35``
Remove unneeded lifetime bound from signature of BTreeSet::extract_if One way to observe the difference between these signatures, using 0 explicit lifetimes and 0 contrived where-clauses: ```rust use std::collections::btree_set::{BTreeSet, ExtractIf}; use std::ops::RangeFull; fn repro( set: &mut BTreeSet<i32>, predicate: impl Fn(i32) -> bool, ) -> ExtractIf<i32, RangeFull, impl FnMut(&i32) -> bool> { set.extract_if(.., move |x| predicate(*x)) } ``` **Before:** ```console error[E0311]: the parameter type `impl Fn(i32) -> bool` may not live long enough --> src/lib.rs:8:5 | 5 | set: &mut BTreeSet<i32>, | ------------------ the parameter type `impl Fn(i32) -> bool` must be valid for the anonymous lifetime defined here... ... 8 | set.extract_if(.., move |x| predicate(*x)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `impl Fn(i32) -> bool` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound | 4 ~ fn repro<'a>( 5 ~ set: &'a mut BTreeSet<i32>, 6 ~ predicate: impl Fn(i32) -> bool + 'a, 7 ~ ) -> ExtractIf<'a, i32, RangeFull, impl FnMut(&i32) -> bool> { | ``` **After:** compiles success. - Tracking issue: rust-lang#70530
Update the `compiler-builtins` subtree Update the Josh subtree to rust-lang/compiler-builtins@7c46e921c117. r? `@ghost`
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 update the subtree/library branch to the changes from 2025-04-24 (rust-lang/rust@df35ff6) to 2025-06-16 (rust-lang/rust@586ad39), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git push
to literally push the changes tosubtree/library
without any rebase or merge.