Merge subtree update for toolchain nightly-2025-10-09 #504
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=80&v=4){kind=small}
This reverts commit 7ce620d. The const-hacks introduces bugs, and they make the code harder to maintain. Let's wait until we can constify these functions without changing their implementation.
Constify Eq, Ord, PartialOrd Adds `#[const_trait]` and impls for `Eq`, `Ord`, `PartialOrd`. Impl for some other traits (e.g., slices and arrays) are blocked mainly on const closures (rust-lang#106003). For TypeId Ord we need const pointer comparison (rust-lang#53020) Tracking issue rust-lang#143800
…rage, r=tgross35 Improve `alloc::Layout` coverage This PR improves the `core::alloc` coverage by adding a new test to `coretests` that cover the `Layout` methods when they error. Tracking issue: rust-lang#55724
…age, r=Noratrieb Improve `core::char` coverage This PR improves the `core::char` coverage by adding new tests to `coretests` r? ``@workingjubilee``
…age, r=jhpratt Improve `core::hash` coverage This PR improves the `core::hash` coverage by adding a new test to `coretests` and extending one of the existing tests to use 128-bit integers r? libs
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 4ba1cf9 Filtered ref: 84b64d836ed478c54972a1d2639e60fa5f3ce26f Upstream diff: rust-lang/rust@2a9bacf...4ba1cf9 This merge was created using https://github.com/rust-lang/josh-sync.
Stabilize BTree{Map,Set}::extract_if
Tracking issue: rust-lang#70530
FCP completed: rust-lang#70530 (comment)
Closes: rust-lang#70530
and document `VaList::arg`.
…rkingjubilee Revert "Constify SystemTime methods" This reverts rust-lang#144519. The const-hacks introduces bugs, and they make the code harder to maintain. Let's wait until we can constify these functions without changing their implementation. Fixes rust-lang#146228. Closes rust-lang#144517 (since the feature is gone). r? `@tgross35` Cc `@clarfonthey`
fix Condvar::wait_timeout docs [Context](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Condvar.20wait_timeout.20sleep.20duration.20decremented/with/539279839) r? `@joboet`
…=workingjubilee document `core::ffi::VaArgSafe` tracking issue: rust-lang#44930 A modification of rust-lang#146454, keeping just the documentation changes, but not unsealing the trait. Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types. This PR also adds some various other tests for edge cases of c-variadic: - the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions. - naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported - guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it. r? `@workingjubilee`
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: a015919 Filtered ref: 1867c5844dba22ac4d77d1ceb7d1624c14139c16 Upstream diff: rust-lang/rust@4ba1cf9...a015919 This merge was created using https://github.com/rust-lang/josh-sync.
This commit performs various improvements (better register allocation,
less register clobbering on the worst case and better readability) of
RISC-V inline assembly use cases.
Note that it does not change the `p` module (which defines the "P"
extension draft instructions but very likely to change).
1. Use `lateout` as possible.
Unlike `out(reg)` and `in(reg)` pair, `lateout(reg)` and `in(reg)`
can share the same register because they state that the late-output
register is written after all the reads are performed.
It can improve register allocation.
2. Add `preserves_flags` option as possible.
While RISC-V doesn't have _regular_ condition codes, RISC-V inline
assembly in the Rust language assumes that some registers
(mainly vector state registers) may be overwritten by default.
By adding `preserves_flags` to the intrinsics corresponding
instructions without overwriting them, it can minimize register
clobbering on the worst case.
3. Use trailing semicolon.
As `asm!` declares an action and it doesn't return a value by
itself, it would be better to have trailing semicolon to denote that
an `asm!` call is effectively a statement.
4. Make most of `asm!` calls multi-lined.
`rustfmt` makes some simple (yet long) `asm!` calls multi-lined but
it does not perform formatting of complex `asm!` calls with inputs
and/or outputs. To keep consistency, it makes most of the `asm!`
calls multi-lined.
Now that this feature has a standard identifier, Darwin has started exposing it accordingly, in addition to the existing less-standard way. Check both, and enable the `crc` feature if either identifier for it is present to ensure backwards and forwards compatibility.
Brings the list of checkable features up to date with the initial release of macOS 26 "Tahoe".
Since PeekMut implements Deref, it shouldn't have any methods of its own. See also: `std::collections::binary_heap::PeekMut::pop`
readdir_r has the same problems on FreeBSD as it does on other platforms: it assumes a fixed NAME_MAX. And readdir has the same thread-safety guarantee as it does on other platforms: it's safe as long as only one thread tries to read from the directory stream at a given time. Furthermore, readdir_r is likely to be removed for FreeBSD 16, so we should stop using it now.
…ross35 std: `sys::net` cleanups This PR contains three improvements to the socket-based networking implementation (aa1263e is just to add the now missing `unsafe`). Best reviewed commit-by-commit.
Implement non-poisoning `Mutex::with_mut`, `RwLock::with` and `RwLock::with_mut` ACP: rust-lang/libs-team#497.
Make `fmt::Write` a diagnostic item I'm working on an enhancement to [`clippy::format_push_string`](https://rust-lang.github.io/rust-clippy/master/index.html#format_push_string), which would suggest an autofix to replace `push_str`/`+=` with `write!`. But that could require importing `std::fmt::Write`, and so I need this diagnostic item to check if it's already in scope. The reason I called it `FmtWrite` and not just `Write` is that there's already an `IoWrite` defined.
…=Noratrieb Improve the advice given by panic_immediate_abort Now that rust-lang#147338 is merged, users should consider using the Cargo support for immediate-aborting panics.
…joboet stdlib docs: document lifetime extension for `format_args!`'s arguments Since rust-lang#140748 is stable and rust-lang#92698 is closed, the section about `format_args!`'s argument lifetime limitation is outdated. I've updated it to point to the Reference docs, which will specify lifetime extension rules for builtin macros once rust-lang/reference#1980 or equivalent is merged. I've also taken the liberty of updating one of the doctests to assign the result of `format_args!` to a variable, both to provide an example and because I think it reads a little better. r? `@m-ou-se`
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#145943 (stdlib docs: document lifetime extension for `format_args!`'s arguments) - rust-lang#147243 (cmse: disallow `impl Trait` in `cmse-nonsecure-entry` return types) - rust-lang#147402 ([rustdoc] Don't serialize & deserialize data that doesn't go OTW) - rust-lang#147418 (Fix target list of `link_section`) - rust-lang#147429 (Print tip for human error format in runtest) - rust-lang#147441 (Fix comments error for Provenance impls) - rust-lang#147442 (c-variadic: fix thir-print for `...` without a pattern) r? `@ghost` `@rustbot` modify labels: rollup
Add a new `wasm32-wasip3` target to Rust This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#146865 (kcfi: only reify trait methods when dyn-compatible) - rust-lang#147205 (Add a new `wasm32-wasip3` target to Rust) - rust-lang#147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`) - rust-lang#147398 (Fix; correct placement of type inference error for method calls) - rust-lang#147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels) - rust-lang#147422 (collect-license-metadata: Print a diff of the expected output) - rust-lang#147431 (compiletest: Read the whole test file before parsing directives) - rust-lang#147433 (Fix doc comment) Failed merges: - rust-lang#147390 (Use globals instead of metadata for std::autodiff) r? `@ghost` `@rustbot` modify labels: rollup
…trochenkov some more `proc_macro` cleanups Several smaller cleanups to `proc_macro`. Commits 1 and 3 seem pretty trivial to me, commit 2 might be worth it or not. Followup to rust-lang#147166.
|
I need to pick up the kids from school now but will look at the VeriFast proof failure after. |
|
@nilehmann I've updated Flux to the latest version available, but seems like there's still bits that need fixing. |
tautschnig
approved these changes
Oct 10, 2025
|
I've created #506, targeting this branch. It merges the upstream changes into the VeriFast proofs. Unfortunately, though, after that update, VeriFast fails on a newly introduced construct. I did not yet look into that. (This will require some VeriFast development. I propose that the present PR be merged without fixing this VeriFast failure, and that I update #481 to also take care of that.) Also, the weird |
This merges the upstream changes into the VeriFast proofs. VeriFast now fails on a newly introduced construct. I'm leaving that for a future commit. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
66 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-09-09 (rust-lang/rust@9c27f27) to 2025-10-09 (rust-lang/rust@b6f0945) (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: 7e44c2b