Merge subtree update for toolchain nightly-2025-11-25 #530
+26,337
−5,598
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
…r=joboet Implement `strip_circumfix` lib feature Tracking issue: rust-lang#147946
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#147137 (Mention crate being analyzed in query description) - rust-lang#147155 (arm-linux.md: various fixes/improvements) - rust-lang#147642 (Miscellaneous const-generics-related fixes) - rust-lang#147806 (Ignore test-dashboard related files) - rust-lang#147947 (Implement `strip_circumfix` lib feature) - rust-lang#148346 (Change cfg_trace, cfg_attr_trace symbol values) - rust-lang#148348 (dangling ptr lint cleanup) - rust-lang#148393 (Remove `tests/run-make/fmt-write-bloat/`) - rust-lang#148400 (Better warning message for crate type unsupported by codegen backend) r? `@ghost` `@rustbot` modify labels: rollup
Constify Range functions Constify various `Range` traits, functions, and implementations
…crum Add `is_ascii` function optimized for LoongArch64 for [u8] Similar to x86_64, on LoongArch64 we use the `vmskltz.b` instruction to test the high bit in a lane. For longer input cases, the performance improvement is significant. For unaligned cases close to 32 bytes in length, there's some regression, but it seems acceptable. | core benches (MB/s) | Before | After | % | |--------------------------------------------------------|--------|--------|---------| | ascii::is_ascii::short::case00_libcore | 1000 | 1000 | 0.00 | | ascii::is_ascii::medium::case00_libcore | 8000 | 8000 | 0.00 | | ascii::is_ascii::long::case00_libcore | 183947 | 436875 | +137.50 | | ascii::is_ascii::unaligned_head_medium::case00_libcore | 7750 | 2818 | -63.64 | | ascii::is_ascii::unaligned_head_long::case00_libcore | 317681 | 436812 | +37.50 | | ascii::is_ascii::unaligned_tail_medium::case00_libcore | 7750 | 3444 | -55.56 | | ascii::is_ascii::unaligned_tail_long::case00_libcore | 155311 | 436812 | +181.25 | | ascii::is_ascii::unaligned_both_medium::case00_libcore | 7500 | 3333 | -55.56 | | ascii::is_ascii::unaligned_both_long::case00_libcore | 174700 | 436750 | +150.00 |
…=Mark-Simulacrum std: don't leak the thread closure if destroying the thread attributes fails The comment about double-free is wrong – we can safely drop both the thread attributes and the thread closure. Here, I've used `DropGuard` for the attributes and moved the `Box::into_raw` to just before the `pthread_create`.
…k-Simulacrum Ignore unix socket related tests for VxWorks Unix Sockets are not implemented in VxWorks, and therefore, ignore testcases related to UnixDatagram, UnixListener and UnixStream.
…s, r=marcoieni Generalize branch references It should be safe to merge this before the rename, and I'd like to do that, so we can test if beta/stable PRs work. r? ``@marcoieni``
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#146573 (Constify Range functions) - rust-lang#146699 (Add `is_ascii` function optimized for LoongArch64 for [u8]) - rust-lang#148026 (std: don't leak the thread closure if destroying the thread attributes fails) - rust-lang#148135 (Ignore unix socket related tests for VxWorks) - rust-lang#148211 (clippy fixes and code simplification) - rust-lang#148395 (Generalize branch references) - rust-lang#148405 (Fix suggestion when there were a colon already in generics) r? `@ghost` `@rustbot` modify labels: rollup
…s, r=jhpratt add SliceIndex wrapper types Last and Clamp<Idx> Tracking issue: rust-lang#146179
…uarantees, r=scottmcm Make explicit that `TypeId`'s layout and size are unstable Or worded differently, explicitly remark non-stable-guarantee of `TypeId` layout and size. This PR makes no *additional* guarantees or non-guarantees, it only emphasizes that `TypeId`'s size and layout are unstable like any other `#[repr(Rust)]` types. This was discussed during [#t-compiler/meetings > [weekly] 2025-10-30 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-10-30/near/547949347), where the compiler team discussed a request rust-lang#148265 to have the standard library (and language) commit to `TypeId` guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was: - We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of `TypeId`, and concerns surrounding its collision-resistance properties rust-lang#10389 and rust-lang#129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved. - Committing to a stability guarantee on the size upper bound now would close the door to making `TypeId` larger (even if unlikely for perf reasons). Given that we have previously broken people who asserted the size of `TypeId` is 8 bytes, it was also discussed in the meeting that we should *explicitly* note that the size and layout of `TypeId` is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix. - So even if `#[repr(Rust)]` types have unstable size and layout, this PR makes it explicit for `TypeId` since this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon. r? `@scottmcm` (or libs/libs-api/lang)
…r=sayantn stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@b5c1645. Created using https://github.com/rust-lang/josh-sync. r? `@sayantn` --- Only the last 2 commits contain manual changes to some incorrect miri tests. The remainder is mechanical, and just synchronizes changes from stdarch.
This PR reverts RUST-147622 for several reasons: 1. The RUST-147622 PR would format the generated core library code using an arbitrary `rustfmt` picked up from `PATH`, which will cause hard-to-debug failures when the `rustfmt` used to format the generated unicode data code versus the `rustfmt` used to format the in-tree library code. 2. Previously, the `unicode-table-generator` tests were not run under CI as part of `coretests`, and since for `x86_64-gnu-aux` job we run library `coretests` with `miri`, the generated tests unfortunately caused an unacceptably large Merge CI time regression from ~2 hours to ~3.5 hours, making it the slowest Merge CI job (and thus the new bottleneck). 3. This PR also has an unintended effect of causing a diagnostic regression (RUST-148387), though that's mostly an edge case not properly handled by `rustc` diagnostics. Given that these are three distinct causes with non-trivial fixes, I'm proposing to revert this PR to return us to baseline. This is not prejudice against relanding the changes with these issues addressed, but to alleviate time pressure to address these non-trivial issues.
Fix documentation for std::panic::update_hook The equivalent code given in the documentation of `std::panic::update_hook`[^1] does not compile: * `set_hook` expects a boxed function * Missing closing delimiter for the closure [^1]: rust-lang#92649
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#135099 (Add FileCheck annotations to mir-opt/copy-prop) - rust-lang#145903 (Give correct suggestion for a typo in raw pointers) - rust-lang#147520 (Port the remaining SIMD intrinsics to const-eval) - rust-lang#148068 (rustdoc: Use configured target modifiers when collecting doctests) - rust-lang#148099 (Prepare to move debugger discovery from compiletest to bootstrap) - rust-lang#148268 (rustdoc: fix `--emit=dep-info` on scraped examples) - rust-lang#148306 (Remove double check when decoding ExpnId to avoid races) - rust-lang#148378 (Fix documentation for std::panic::update_hook) r? `@ghost` `@rustbot` modify labels: rollup
Forward `TEST_SAMPLE_INTRINSICS_PERCENTAGE`
Add intrinsics for the new AMX target features
…, r=dtolnay Stabilize `fmt::from_fn` Resolves rust-lang#146705, pending its FCP. As discussed in that tracking issue and rust-lang#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
feat: add `from_fn_ptr` to `Waker` and `LocalWaker` Closes: rust-lang#146055
library: std: sys: net: uefi: tcp: Implement write_vectored - A working vectored write implementation for TCP4. - Also introduces a small helper UefiBox intended to be used with heap allocated UEFI DSTs. - Tested on OVMF cc ```@nicholasbishop```
…sDenton std: sys: fs: uefi: Fix FileAttr size - The underlying file size is represented by file_size field. The size field is just the size of structure since it is a C DST. - Fixes bug created in rust-lang#148970 ``@rustbot`` label +O-UEFI
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#149033 (autodiff rlib handling) - rust-lang#149088 (Add missing trailing period to RustDoc for fn create_dir().) - rust-lang#149111 (fs: Run file lock tests on all platforms that support it) - rust-lang#149113 (sgx: avoid unnecessarily creating a slice) - rust-lang#149123 (std: sys: fs: uefi: Fix FileAttr size) - rust-lang#149133 (Remove an unused variable) - rust-lang#149139 (Enable host tools for aarch64-unknown-linux-ohos) - rust-lang#149144 (Reject `async fn` in `const impl` during AST validation) - rust-lang#149154 (Fix platform supports docs tiny typo) r? `@ghost` `@rustbot` modify labels: rollup
…inder_is_non_optional, r=dtolnay unwrap ret ty of `iter::ArrayChunks::into_remainder` changes [`iter::ArrayChunks::into_remainder`](rust-lang#100450) to return `array::IntoIter` instead of `Option<array::IntoIter>` as suggested by [`@WaffleLapkin](https://github.com/rust-lang/rust/issues/100450#issuecomment-3555519025)`
std: sys: net: uefi: Implement read_vectored - Basically a copy of write_vectored [0] - Tested on QEMU ovmf. [0]: rust-lang#146301
…pe, r=scottmcm Constify `residual_into_try_type` Feature: `const_try_residual` (related to `try_trait_v2_residual`) Tracking issue: rust-lang#91285 Constify `residual_into_try_type` introduced in rust-lang#148725. r? ``@scottmcm``
…Amanieu library: upgrade to hashbrown v0.16.1 This is another step toward unspecializing `Copy`. See also rust-lang#135634 and rust-lang/hashbrown#662 r? `@Amanieu` cc `@joboet`
…s, r=JonathanBrouwer
Warn against calls which mutate an interior mutable `const`-item
## `const_item_interior_mutations`
~~`interior_mutable_const_item_mutations`~~
~~`suspicious_mutation_of_interior_mutable_consts`~~
*warn-by-default*
The `const_item_interior_mutations` lint checks for calls which mutates an interior mutable const-item.
### Example
```rust
use std::sync::Once;
const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
// never modify it-self on use, should be a `static`
// instead for shared use
fn init() {
INIT.call_once(|| {
println!("Once::call_once first call");
});
}
```
```text
warning: mutation of an interior mutable `const` item with call to `call_once`
--> a.rs:11:5
|
11 | INIT.call_once(|| {
| ^---
| |
| _____`INIT` is a interior mutable `const` item of type `std::sync::Once`
| |
12 | | println!("Once::call_once first call");
13 | | });
| |______^
|
= note: each usage of a `const` item creates a new temporary
= note: only the temporaries and never the original `const INIT` will be modified
= help: for more details on interior mutability see <https://doc.rust-lang.org/reference/interior-mutability.html>
= note: `#[warn(const_item_interior_mutations)]` on by default
help: for a shared instance of `INIT`, consider making it a `static` item instead
|
6 - const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
6 + static INIT: Once = Once::new(); // using `INIT` will always create a temporary and
|
```
### Explanation
Calling a method which mutates an interior mutable type has no effect as const-item are essentially inlined wherever they are used, meaning that they are copied directly into the relevant context when used rendering modification through interior mutability ineffective across usage of that const-item.
The current implementation of this lint only warns on significant `std` and `core` interior mutable types, like `Once`, `AtomicI32`, ... this is done out of prudence and may be extended in the future.
----
This PR is an targeted alternative to rust-lang#132146. It avoids false-positives by adding an internal-only attribute `#[rustc_should_not_be_called_on_const_items]` on methods and functions that mutates an interior mutale type through a shared reference (mutable refrences are already linted by the `const_item_mutation` lint).
It should also be noted that this is NOT an uplift of the more general [`clippy::borrow_interior_mutable_const`](https://rust-lang.github.io/rust-clippy/master/index.html#/borrow_interior_mutable_const) lint, which is a much more general lint regarding borrow of interior mutable types, but has false-positives that are completly avoided by this lint.
A simple [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%28%3F-i%29const+%5Ba-zA-Z0-9_%5D*%3A+Once%2F&type=code) reveals many instance where the user probably wanted to use a `static`-item instead.
----
````@rustbot```` labels +I-lang-nominated +T-lang
cc ````@traviscross````
r? compiler
Fixes [IRLO - Forbidding creation of constant mutexes, etc](https://internals.rust-lang.org/t/forbidding-creation-of-constant-mutexes-etc/19005)
Fixes rust-lang#132028
Fixes rust-lang#40543
Move safe computation out of unsafe block
Fix typo in HashMap performance comment
|
Great; the logic for patching the VeriFast proofs in the Subtree Update workflow seems to work as intended: the proofs that it can successfully patch (LinkedList) are patched; the other ones (RawVec) are left alone. I will look into the RawVec proof in the coming days. It's up to you whether you prefer to merge this PR with the failing VeriFast proof, or to wait (probably a few days) for me to fix it. |
Member
Thank you very much! I don't think we need to rush, there's more cleanup required on this PR anyway to make all other CI pass. |
Member
|
@nilehmann It looks like Flux requires a toolchain update. @rafaelsamenezes ESBMC segfaults, could you please take a look? |
|
This may take us longer than usual, so please go ahead and merge if we don't have the fix soon enough. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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-10-09 (rust-lang/rust@b6f0945) to 2025-11-25 (rust-lang/rust@c871d09) (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: e3e34e0