-
Notifications
You must be signed in to change notification settings - Fork 58
Merge subtree update for toolchain nightly-2025-10-09 #504
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
base: main
Are you sure you want to change the base?
Conversation
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`
…cm,tgross35 add mem::conjure_zst Tracking issue: rust-lang#95383
…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. |
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 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 merge
resulted 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