Merge subtree update for toolchain nightly-2025-07-14 #418
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}
…x, r=jhpratt impl `Default` for `array::IntoIter` cc rust-lang#91583 my personal use of this feature comes from https://github.com/fee1-dead/w/blob/092db5df631ea515b688bae99c7f02eef12d7221/src/cont.rs#L154-L170 insta-stable, but I feel like this is small enough to _not_ require an ACP (but a FCP per https://forge.rust-lang.org/libs/maintaining-std.html#when-theres-new-trait-impls)? feel free to correct me if I am wrong.
Add support for repetition to `proc_macro::quote` Progress toward: rust-lang#140238
…lacrum Windows: Use anonymous pipes in Command When setting `Stdio::pipe` on `Command` we want to create an anonymous pipe that can be used asynchronously (at least on our end). Usually we'd use [`CreatePipe`](https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createpipe) to open anonymous pipes but unfortunately it opens pipes for synchronous access. The alternative is to use [`CreateNamedPipeW`](https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createnamedpipew) which does allow asynchronous access but that requires giving a file name to the pipe. So we currently have this awful hack where we attempt to emulate anonymous pipes using `CreateNamedPipeW` by attempting to create a unique name and looping until we find one that doesn't already exist. The better option is to use the lower level [`NtCreateNamedPipeFile`](https://learn.microsoft.com/en-us/windows/win32/devnotes/nt-create-named-pipe-file) (which is used internally by both `CreatePipe` and `CreateNamedPipeW`). This function wasn't documented until a few years ago but now that it is it's ok for us to use it. try-job: *msvc* try-job: *mingw*
alloc: less static mut + some cleanup I'm looking into rust-lang#125035 and would like some feedback on my approach.
… r=jhpratt Remove a panicking branch in `BorrowedCursor::advance`
This recently spuriously failed in a rollup, so I think we can afford to increase the base timeout and the amount of time slept for to provide a much wider margin for the timeout to be reached.
Safer implementation of RepeatN I've seen the "Use MaybeUninit for RepeatN" commit while reading This Week In Rust and immediately thought about something I've written some time ago - https://github.com/Soveu/repeat_finite/blob/master/src/lib.rs. Using the fact, that `Option` will find niche in `(T, NonZeroUsize)`, we can construct something that has the same size as `(T, usize)` while completely getting rid of `MaybeUninit`. This leaves only `unsafe` on `TrustedLen`, which is pretty neat.
This uses `super let` to allow
let f = format_args!("Hello {}", world);
println!("{f}");
to work.
Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? `@bjorn3` cc `@jieyouxu`
…r, r=lcnr,traviscross Stabilize `feature(generic_arg_infer)` Fixes rust-lang#85077 r? lcnr cc ````@rust-lang/project-const-generics````
…r=bjorn3 remove duplicate crash test I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong? r? ``@bjorn3``
…nner, r=tgross35 Get rid of `EscapeDebugInner`. I read the note on `EscapeDebugInner` and thought I'd give it a try.
…r=bjorn3 remove duplicate crash test I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong? r? ```@bjorn3```
Rollup of 6 pull requests Successful merges: - rust-lang#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused) - rust-lang#138237 (Get rid of `EscapeDebugInner`.) - rust-lang#141614 (lint direct use of rustc_type_ir ) - rust-lang#142123 (Implement initial support for timing sections (`--json=timings`)) - rust-lang#142377 (Try unremapping compiler sources) - rust-lang#142674 (remove duplicate crash test) r? `@ghost` `@rustbot` modify labels: rollup
…oes. Add a doctest with a non-empty-by-default iterator.
…ulacrum
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 31 packages to latest compatible versions
Updating adler2 v2.0.0 -> v2.0.1
Updating cfg-if v1.0.0 -> v1.0.1
Updating clap v4.5.39 -> v4.5.40
Updating clap_builder v4.5.39 -> v4.5.40
Updating clap_derive v4.5.32 -> v4.5.40
Updating clap_lex v0.7.4 -> v0.7.5
Updating getopts v0.2.21 -> v0.2.23
Updating hermit-abi v0.5.1 -> v0.5.2
Updating jiff v0.2.14 -> v0.2.15
Updating jiff-static v0.2.14 -> v0.2.15
Updating libc v0.2.172 -> v0.2.173
Updating memchr v2.7.4 -> v2.7.5
Updating minifier v0.3.5 -> v0.3.6
Updating miniz_oxide v0.8.8 -> v0.8.9
Updating object v0.37.0 -> v0.37.1
Updating redox_syscall v0.5.12 -> v0.5.13
Updating rustc-demangle v0.1.24 -> v0.1.25
Updating syn v2.0.101 -> v2.0.103
Updating thread_local v1.1.8 -> v1.1.9
Updating unicode-width v0.2.0 -> v0.2.1
Updating wasi v0.11.0+wasi-snapshot-preview1 -> v0.11.1+wasi-snapshot-preview1
Updating wasm-encoder v0.233.0 -> v0.235.0
Removing wasmparser v0.232.0
Removing wasmparser v0.233.0
Adding wasmparser v0.234.0
Adding wasmparser v0.235.0
Updating wast v233.0.0 -> v235.0.0
Updating wat v1.233.0 -> v1.235.0
Updating windows v0.61.1 -> v0.61.3
Updating windows-link v0.1.1 -> v0.1.3
Adding windows-sys v0.60.2
Updating windows-targets v0.53.0 -> v0.53.2
Updating winnow v0.7.10 -> v0.7.11
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating libc v0.2.172 -> v0.2.173
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 19 packages to latest compatible versions
Updating adler2 v2.0.0 -> v2.0.1
Updating cc v1.2.26 -> v1.2.27
Updating cfg-if v1.0.0 -> v1.0.1
Updating clap v4.5.39 -> v4.5.40
Updating clap_builder v4.5.39 -> v4.5.40
Updating clap_complete v4.5.52 -> v4.5.54
Updating clap_derive v4.5.32 -> v4.5.40
Updating clap_lex v0.7.4 -> v0.7.5
Updating getopts v0.2.21 -> v0.2.23
Updating jiff v0.2.14 -> v0.2.15
Updating jiff-static v0.2.14 -> v0.2.15
Updating libc v0.2.172 -> v0.2.173
Updating memchr v2.7.4 -> v2.7.5
Updating miniz_oxide v0.8.8 -> v0.8.9
Updating redox_syscall v0.5.12 -> v0.5.13
Updating syn v2.0.101 -> v2.0.103
Removing unicode-width v0.1.14
Removing unicode-width v0.2.0
Adding unicode-width v0.2.1
Updating windows-link v0.1.1 -> v0.1.3
Updating winnow v0.7.10 -> v0.7.11
```
…ctor-on-mpmc-test, r=joshtriplett library: Increase timeout on mpmc test to reduce flakes This recently spuriously failed in a rollup, so I think we can afford to increase the base timeout and the amount of time slept for to provide a much wider margin for the timeout to be reached.
It is currently possible to create a dangling `Weak` to a DST by calling `Weak::new()` for a sized type, then doing an unsized coercion. Therefore, the comments are wrong. These comments were added in <rust-lang#73845>. As far as I can tell, the guarantee in the comment was only previously used in the `as_ptr` method. However, the current implementation of `as_ptr` no longer relies on this guarantee.
Handle win32 separator for cygwin paths This PR handles a issue that cygwin actually supports Win32 path, so we need to handle the Win32 prefix and separaters. r? `@mati865` cc `@jeremyd2019` ~~Not sure if I should handle the prefix like the windows target... Cygwin *does* support win32 paths directly going through the APIs, but I think it's not the recommended way.~~ Here I just use `cygwin_conv_path` because it handles both cygwin and win32 paths correctly and convert them into absolute POSIX paths. UPDATE: Windows path prefix is handled.
…t, r=tgross35 Simplify num formatting helpers Noticed `ilog10` was being open-coded when looking at this diff: https://github.com/rust-lang/rust/pull/143423/files/85d6768f4c437a0f3799234df20535ff65ee17c2..76d9775912ef3a7ee145053a5119538bf229d6e5#diff-6be9b44b52d946ccac652ddb7c98146a01b22ea0fc5737bc10db245a24796a45 That, and two other small cleanups 😁 (should probably go through perf just to make sure it doesn't regress formatting)
Make `Default` const and add some `const Default` impls Full list of `impl const Default` types: - () - bool - char - std::ascii::Char - usize - u8 - u16 - u32 - u64 - u128 - i8 - i16 - i32 - i64 - i128 - f16 - f32 - f64 - f128 - std::marker::PhantomData<T> - Option<T> - std::iter::Empty<T> - std::ptr::Alignment - &[T] - &mut [T] - &str - &mut str - String - Vec<T>
instead of a new panic For unwinding with SEH, we currently construct a C++ exception with the panic data. Being a regular C++ exception, it interacts with the C++ exception handling machinery and can be retrieved via `std::current_exception`, which needs to copy the exception. We can't support that, so we panic, which throws another exception, which the C++ runtime tries to copy and store into the exception_ptr, which panics again, which causes the C++ runtime to store a `bad_exception` instance. However, this doesn't work because the panics thrown by the copy function will be dropped without being rethrown, and causes unnecessary log spam in stderr. Fix this by directly throwing an exception without data, which doesn't cause log spam and can be dropped without being rethrown.
Bootstrap already had a manual doc filter for the `sysroot` crate, but other library crates keep themselves out of the public docs by setting `[lib] doc = false` in their manifest. This seems like a better solution to hide `compiler-builtins` docs, and removes the `sysroot` hack too.
clippy fix: indentation Fixes indentation of markdown comments.
Update the `compiler-builtins` subtree Update the Josh subtree to rust-lang/compiler-builtins@8aba4c899ee8. r? `@ghost`
Add opaque TypeId handles for CTFE Reopen of rust-lang#142789 (comment) after some bors insta-merge chaos r? `@RalfJung`
…=petrochenkov Fix `proc_macro::Ident`'s handling of `$crate` This PR is addresses a few minor bugs, all relating to `proc_macro::Ident`'s support for `$crate`. `Ident` currently supports `$crate` (as can be seen in the `mixed-site-span` test), but: * `proc_macro::Symbol::can_be_raw` is out of sync with `rustc_span::Symbol::can_be_raw` * former doesn't cover `$crate` while the latter does cover `kw::DollarCrate` * `Ident::new` rejects `$crate` * This conflicts with the [reference definition](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#r-macro.decl.meta.specifier) of `ident` which includes `$crate`. * This also conflicts with the documentation on [`Display for Ident`](https://doc.rust-lang.org/proc_macro/struct.Ident.html#impl-Display-for-Ident) which says the output "should be losslessly convertible back into the same identifier". This PR fixes the above issues and extends the `mixed-site-span` test to exercise these fixed code paths, as well as validating the different possible spans resolve `$crate` as expected (for both the new and old `$crate` construction code paths).
…heemdev Mention as_chunks in the docs for chunks and `as_rchunks_mut` from `rchunks_exact_mut`, and such. As suggested in rust-lang#76354 (comment) (but does not close that issue).
…gross35 Move NaN tests to floats/mod.rs This PR moves NaN tests to `floats/mod.rs`, as discussed in rust-lang#141726. Since this is my first PR against Rust, I'm keeping it as small as possible, but I intend to work my way through the remaining tests and can do that work in this PR if that's preferable. r? RalfJung
Rollup of 9 pull requests Successful merges: - rust-lang#141996 (Fix `proc_macro::Ident`'s handling of `$crate`) - rust-lang#142950 (mbe: Rework diagnostics for metavariable expressions) - rust-lang#143011 (Make lint `ambiguous_glob_imports` deny-by-default and report-in-deps) - rust-lang#143265 (Mention as_chunks in the docs for chunks) - rust-lang#143270 (tests/codegen/enum/enum-match.rs: accept negative range attribute) - rust-lang#143298 (`tests/ui`: A New Order [23/N]) - rust-lang#143396 (Move NaN tests to floats/mod.rs) - rust-lang#143398 (tidy: add support for `--extra-checks=auto:` feature) - rust-lang#143644 (Add triagebot stdarch mention ping) r? `@ghost` `@rustbot` modify labels: rollup
…re-body, r=oli-obk Add checking for unnecessary delims in closure body Fixes rust-lang#136741
…, r=compiler-errors docs: document trait upcasting rules in `Unsize` trait The trait upcasting feature stabilized in 1.86 added new `Unsize` implementation, but this wasn't reflected in the trait's documentation.
Fix VxWorks build errors fixes rust-lang#143442 r? ``@Noratrieb``
…r-errors Constify `Fn*` traits r? `@compiler-errors` `@fee1-dead` this should unlock a few things. A few `const_closures` tests have broken even more than before, but that feature is marked as incomplete anyway cc rust-lang#67792
…isDenton Win: Use exceptions with empty data for SEH panic exception copies instead of a new panic For unwinding with SEH, we currently construct a C++ exception with the panic data. Being a regular C++ exception, it interacts with the C++ exception handling machinery and can be retrieved via `std::current_exception`, which needs to copy the exception. We can't support that, so we panic, which throws another exception, which the C++ runtime tries to copy and store into the exception_ptr, which panics again, which causes the C++ runtime to store a `bad_exception` instance. However, this doesn't work because the panics thrown by the copy function will be dropped without being rethrown, and causes unnecessary log spam in stderr. Fix this by directly throwing an exception without data, which doesn't cause log spam and can be dropped without being rethrown. Fixes rust-lang#143623. This also happens to be the solution ``@dpaoliello`` suggested, though I'm not sure how to handle the commit credit attribution.
Disable docs for `compiler-builtins` and `sysroot` Bootstrap already had a manual doc filter for the `sysroot` crate, but other library crates keep themselves out of the public docs by setting `[lib] doc = false` in their manifest. This seems like a better solution to hide `compiler-builtins` docs, and removes the `sysroot` hack too. Fixes rust-lang#143215 (after backport) ```@rustbot``` label beta-nominated
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 merge library subtree updates from 2025-07-02 (rust-lang/rust@71e4c00) to 2025-07-14 (rust-lang/rust@e9182f1) (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: 1dc1e2d