Update subtree/library to 2025-06-17 #391
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Add that the enum must be `#[repr(Rust)]` and not `#[repr(packed)]` or `#[repr(align)]` in order to be ABI-compatible with its null-pointer-optimized field.
The unexpected configs are now unused or known to `rustc` in our CI.
- Rewords existing Considerations section on `fetch_update` and friends to make clear that the limitations are inherent to an implementation based on any CAS operation, rather than the weak version of `compare_exchange` in particular - Add Considerations to `compare_exchange` and `compare_exchange_weak` which details similar considerations and when they may be relevant.
This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1]. [1]: rust-lang#142265
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. Also includes the minor bump from 0.37.0 to 0.37.1 to help [1]. Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370 [1]: rust-lang#142265
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
This comes with a `gimli` upgrade, so we no longer have two different versions.
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
Signed-off-by: xizheyin <[email protected]>
This allows UTF-8 characters to be printed without escapes, rather than just ASCII.
…e, r=dtolnay Added `Clone` implementation for `ChunkBy` Added `Clone` implementation for `ChunkBy` Closes rust-lang#137969.
…traviscross Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field. Add that the enum must be `#[repr(Rust)]` and not `#[repr(packed)]` or `#[repr(align)]` in order to be ABI-compatible with its null-pointer-optimized field. The specific rules here were decided on here: rust-lang#130628 (comment) but `repr` was not mentioned. In practice, only `#[repr(Rust)]` (or no `repr` attribute, which is equivalent) works for this, so add that to the docs. ----- Restrict to `#[repr(Rust)]` only, since: * `#[repr(C)]` and the primitive representations (`#[repr(u8)]` etc) definitely disqualify the enum from NPO, since they have defined layouts that store the tag separately to the payload. * `#[repr(transparent)]` enums are covered two bullet points above this (line 1830), and cannot have multiple variants, so would fail the "The enum has exactly two variants" requirement anyway. As for `#[repr(align)]`: my current wording that it is completely disallowed may be too strong: it seems like `#[repr(align(<= alignment of T))] enum Foo { X, Y(T) }` currently does still have the same ABI as `T` in practice, though this may not be something we want to promise. (`#[repr(align(> alignment of T))]` definitely disqualifies the enum from being ABI-compatible with T currently). I added the note about `packed` to match `align`, but `#[repr(packed)]` currently can't be applied to `enum`s at all anyway, so might be unnecessary. ----- I think this needs T-lang approval? cc ``````@workingjubilee``````
Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations ## Motivation The existing documentation for atomic `fetch_update` (and other similar methods) has a section that reads like so: > ### Considerations > This method is not magic; it is not provided by the hardware. It is implemented in > terms of `AtomicBlah::compare_exchange_weak`, and suffers from the same drawbacks. > In particular, this method will not circumvent the [ABA Problem]. > > [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem The wording here seems to imply that the drawbacks being discusses are caused by the *`weak` version* of `compare_exchange`, and that one may avoid those drawbacks by using `compare_exchange` instead. Indeed, a conversation in the `#dark-arts` channel on the Rust community discord based on this interpretation led to this PR. In reality, the drawbacks are inherent to implementing such an operation based on *any* compare-and-swap style operation, as opposed to an [LL,SC](https://en.wikipedia.org/wiki/Load-link/store-conditional) operation, and they apply equally to `compare_exchange` and `compare_exchange_weak` as well. ## Changes - Rewords existing Considerations section on `fetch_update` and friends to make clear that the limitations are inherent to an implementation based on any CAS operation, rather than the weak version of `compare_exchange` in particular. New version: > ### Considerations > > This method is not magic; it is not provided by the hardware, and does not act like a > critical section or mutex. > > It is implemented on top of an atomic [compare-and-swap operation], and thus is subject to > the usual drawbacks of CAS operations. In particular, be careful of the [ABA problem] > if this atomic integer is an index or more generally if knowledge of only the *bitwise value* > of the atomic is not in and of itself sufficient to ensure any required preconditions. > > [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem > [compare-and-swap operation]: https://en.wikipedia.org/wiki/Compare-and-swap - Add Considerations to `compare_exchange` and `compare_exchange_weak` which details similar considerations and when they may be relevant. New version: > ### Considerations > > `compare_exchange` is a [compare-and-swap operation] and thus exhibits the usual downsides > of CAS operations. In particular, a load of the value followed by a successful > `compare_exchange` with the previous load *does not ensure* that other threads have not > changed the value in the interim. This is usually important when the *equality* check in > the `compare_exchange` is being used to check the *identity* of a value, but equality > does not necessarily imply identity. In this case, `compare_exchange` can lead to the > [ABA problem]. > > [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem > [compare-and-swap operation]: https://en.wikipedia.org/wiki/Compare-and-swap
…rors,traviscross
Lint on fn pointers comparisons in external macros
This PR extends the recently stabilized `unpredictable_function_pointer_comparisons` lint ~~to also lint on `Option<{function pointer}>` and~~ as well as linting in external macros (as to catch `assert_eq!` and others).
```rust
assert_eq!(Some::<FnPtr>(func), Some(func as unsafe extern "C" fn()));
//~^ WARN function pointer comparisons
#[derive(PartialEq, Eq)]
struct A {
f: fn(),
//~^ WARN function pointer comparisons
}
```
Fixes rust-lang#134527
…orkingjubilee chore(doctest): Remove redundant blank lines Remove redundant leading blank lines from doctests of [`iN::cast_unsigned`](https://doc.rust-lang.org/std/primitive.i32.html#method.cast_unsigned), [`slice::escape_ascii`](https://doc.rust-lang.org/std/primitive.slice.html#method.escape_ascii) and [`u8::escape_ascii`](https://doc.rust-lang.org/std/primitive.u8.html#method.escape_ascii).
This allows UTF-8 characters to be printed without escapes, rather than just ASCII.
…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`
…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
…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>
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-06-03 (rust-lang/rust@5d707b0) to 2025-06-17 (rust-lang/rust@45acf54), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git pushto literally push the changes tosubtree/librarywithout any rebase or merge.