Conversation
…unimplemented, r=estebank Avoid redundant note when a #[derive] is already suggested Fixes rust-lang/rust#157118 The `Debug` `#[rustc_on_unimplemented]` note ("add `#[derive(Debug)]` to `X` or manually `impl Debug for X`") just repeats the `consider annotating X with #[derive(..)]` suggestion that `suggest_derive` already emits, so on these bound errors it's pure noise. Now the note only gets dropped when that suggestion will actually show, which is whenever `can_suggest_derive` holds: a crate-local ADT, not a union, with every field already implementing the trait. Deleting the note from the attribute outright would be too blunt, since when `can_suggest_derive` is false there's no suggestion and the note is the only hint the user gets. A crate-local struct with a non-`Debug` field still ends up with just: ``` error[E0277]: `Outer` doesn't implement `Debug` = note: add `#[derive(Debug)]` to `Outer` or manually `impl Debug for Outer` ``` Same story when `main_trait_predicate != leaf_trait_predicate`, since the note comes from the main predicate and the suggestion from the leaf.
std: Refactor `env::var` function
std::process: uefi: avoid panicking in Stdio From impls. map io::Stdout/Stderr to Stdio::Inherit and File to a new InheritFile variant returning io::Error from output() instead of aborting.
…pratt Migrate libraries from ptr::slice_from_raw_parts to .cast_slice Tracking issue for `#![feature(ptr_cast_slice)]`: rust-lang/rust#149103 This commit updates most callsites of ptr::slice_from_raw_parts within ./library to the more concise but unstable postfix `.cast_slice()` method on raw pointers, using the `ptr_cast_slice` feature. Some tests in alloctests have also been updated. No functional change, debatably improved readability.
`offload_kernel` macro expansion r? @ZuseZ4
…, r=camelid Add regression test Fixes rust-lang/rust#84827.
elaborate_drop: Avoid as_mut.unwrap dance, empty vectors are cheap. Nit I found while working on rust-lang/rust#156649
…uwer Rollup of 8 pull requests Successful merges: - rust-lang/rust#157006 (net tests: let the OS pick the port numbers) - rust-lang/rust#157126 (Avoid redundant note when a #[derive] is already suggested) - rust-lang/rust#151690 (std: Refactor `env::var` function) - rust-lang/rust#155826 (std::process: uefi: avoid panicking in Stdio From impls.) - rust-lang/rust#156109 (Migrate libraries from ptr::slice_from_raw_parts to .cast_slice) - rust-lang/rust#156642 (`offload_kernel` macro expansion) - rust-lang/rust#156823 (Add regression test) - rust-lang/rust#157162 (elaborate_drop: Avoid as_mut.unwrap dance, empty vectors are cheap.) Failed merges: - rust-lang/rust#157173 (rustc-dev-guide subtree update)
…ooeo Add regression test for issue #87290 Issue rust-lang/rust#87290 is labeled E-needs-test for explicit non-`'static` lifetimes in closure argument types. This adds a check-pass UI test for explicit lifetimes in closure argument types. Fixes rust-lang/rust#87290.
…ivooeo Don't suggest semicolon after if expression closing brace When a type mismatch occurs inside an if expression, the compiler incorrectly suggests adding a semicolon after the closing brace. This doesn't fix the error. The fix excludes all if expressions from the suggest_semicolon_at_end suggestion in coercion.rs. Fix: rust-lang/rust#156621
rustdoc: optimize impl sorting Currently rustdoc sorts impls in a couple of places using long HTML string representations of the impls. Using plain text representations instead speeds things up. Details in individual commits.
[Debug Info] replace `lldb_commands` with `__lldb_init_module` ~~DO NOT MERGE~~. Please run through `aarch64-apple`. Ideally the tests fail. If they don't, the test runner is using too old of a version of LLDB and I need to fiddle with this some more. TL;DR I hate `lldb_commands`, it's annoying to update and maintain since it's just a raw text file of CLI commands. All of the functionality can be replicated via the debugger's own API. `__lldb_init_module` is called immediately upon `command script import lldb_lookup.py`, so it should function identically (with one exception, see below). We can do things like let python tell us the names of the functions and classes, making them easier to keep in sync. Most importantly, we can conditionally use one set of visualizers or another depending on the version of the debugger. This is a precursor to using callback-based type matching, which was added in LLDB 19. The one exception i mentioned above replaces our `".*"` regex that dumps everything through `lldb_lookup.synthetic_lookup`. That wildcard also includes primitives which is less than ideal, especially for performance. It's bad enough that [codelldb intercepts this command and replaces it with a type recognizer](https://github.com/vadimcn/codelldb/blob/39d9accd8c666e3d3d1372abccad12b3d256ed0b/lang_support/rust.py#L50). If i remove `lldb_commands`, codelldb can no longer do this. To prevent a regression on their end, I added [a conditional that replicates that behavior](https://github.com/Walnut356/rust/blob/e4db5e7ccba109dea635b9140cb9f54b6378abf3/src/etc/lldb_lookup.py#L145). Here's the problem: for some godforsaken reason, if a struct contains a field with a `SyntheticProvider` (even one that is "empty", like for `DefaultSyntheticProvider` for primitives) **it is formatted differently than a struct whose fields don't have providers**. That breaks a bunch of the tests because instead of `{ x = 10 y = 30 }` we get `(x = 10, y = 30)`. Very cool. So, we have divergent behavior depending on the version of LLDB. That's nothing new, since MSVC enums are broken prior to LLDB 18, so it's whatever (and the difference hardly matters to the end user). If the CI test runners have a new enough version of LLDB that it uses the type recognizer instead of the wildcard, the tests will fail. I'll update them and we'll be good to go. If they *don't* fail, I need to probably force a struct summary provider so that all versions look the same (which isn't ideal performance), or I can just wait until xcode happens to update to a newer version of LLDB. --- try-job: aarch64-apple
Add bootstrap step for stdarch-verify
This PR hooks `library/stdarch/crates/stdarch-verify` crate into the bootstrap test runner as a step, so that we can run the stdarch-verify suite via x.py test.
Changes :
-> Added StdarchVerify in `src/bootstrap/src/core/build_steps/test.rs`
-> Added `test::StdarchVerify` in `src/bootstrap/src/core/builder/mod.rs`
Tests:
-> Running `./x.py test library/stdarch/crates/stdarch-verify` builds compiler and std successfully.
-> All three integration tests Passes:
tests/arm.rs
tests/mips.rs
tests/x86-intel.rs
-> Doc tests for `stdarch_verify` also Passes.
r? @Kobzol
try-job: x86_64-gnu-distcheck
Expand async drops during drop elaboration Async drops implemented by rust-lang/rust#123948 are expanded in await loops inside `StateTransform`. I find this odd, as `StateTransform` is tasked with removing yields from MIR. This PR moves this `async drop` -> loop transformation to drop elaboration. The first few commits create many mir-opt tests to gauge the effect of following commits. I can easily trim those. The next few commits are from rust-lang/rust#156422. Then come a few commits performing elementary simplifications to drop elaboration code. The most important commit is `Expand async drops during drop elaboration.` It performs the main change and attempts to document what I had to understand doing that. The last commit is a cleanup. This is a large PR, but most of the diff is in generated files. I can easily split them, each commit compiles and passes tests on its own. cc @zetanumbers
introduce UnevaluatedConstKind (no rush on this, boxy, if you get this notif, I know you're on break after rustweek) Partially fixes rust-lang/project-const-generics#98 - does not unify GCE `ConstKind::Expr` into Unevaluated, which is part of that issue - does not do more advanced refactoring to take advantage of the new kind repr, only refactoring when things are very obviously able to take advantage - does not change MIR's UnevaluatedConst to use UnevaluatedConstKind, as there's currently no benefit, and doing so instead overcomplicates many places. Possibly could be done in a followup, or I can do it here if desired. - more advanced potentially behavior-changing changes can be done in a followup, as this diff is big enough as it is, IMO. same with merging GCE Exprs into Unevaluated. - (... but if this takes a while to get reviewed, I might plop some more stuff into this PR) - I think it would be cute to rename UnevaluatedConst to AliasConst or something, to better reflect the parallels to AliasTy, but shrug, haha r? @BoxyUwU
`LivenessValues`: use dedicated enum rather than mutually exclusive `Option`s I was reading through `LivenessValues` and realised it had a lot of comments explaining that two `Option`s were mutually exclusive, plus some redundant logic to handle this. This is a drive-by fix to use ~~an `Either`~~ a dedicated enum instead, which makes that property obvious from the code. It also removes the repeated logic.
Remove `skip_arg` attribute from `Diagnostic` and `Subdiagnostic` proc-macros
Instead of having users to manually add `#[skip_arg]` for each field that is not used in fluent messages, I think it's better to instead let the proc-macro only call `diag.arg("name", field)` on the fields actually used.
r? @JonathanBrouwer
rustc_target: Use +spe for powerpcspe targets LLVM does not infer this from the target name and `abi: "spe"` is just for cfg. To actually generate the correct instructions for these targets (without `-C target-cpu`), we need to pass `+spe` to LLVM. Fixes rust-lang/rust#138960 See also rust-lang/rust#157085 Related rust-lang/rust#137860 cc @RalfJung cc @BKPepe ([powerpc-unknown-linux-muslspe target maintainer](https://doc.rust-lang.org/nightly/rustc/platform-support/powerpc-unknown-linux-muslspe.html#target-maintainers)) cc @glaubitz (who added powerpc-unknown-linux-gnuspe in rust-lang/rust#48484) cc @biabbas @hax0kartik ([*-wrs-vxworks target maintainers](https://doc.rust-lang.org/nightly/rustc/platform-support/vxworks.html#target-maintainers)) @rustbot label +O-PowerPC +A-target-feature
Implement argument-dependent target checking for the `#[repr]` parser Fixes some of rust-lang/rust#156499 Fixes some of rust-lang/rust#153101 Alternative approach to rust-lang/rust#156569, which was suggested in the comments here: rust-lang/rust#156569 (review) How do you feel about this approach? r? @mejrs
additional changes for issue-144595 - add spaces between the braces @ada4a - remove `:` in the help message. I learn this from estebank ("In the text we don't include a trailing :, unless we have a very specific reason. These messages can render in the terminal, in different ways, or in IDEs. Having a : can look out of place in some cases, specifically in rust-analyzer in VSCode is one of them.") - suggest to use `::` for any colon encountered in tuple struct. So it now display help message for `std::string:String`. The same logic also appears in `parse_block_tail`, it suggest the user to use `::` when `parse_full_stmt` stops at a colon. So I think it's okay to make this change. r? mejrs
Remove unnecessary arm in `handle_res` Just nits found when reading the code
Add test for undefined EII static error Meant to add this to rust-lang/rust#156923, but pushed to the wrong branch. r? @jdonszelmann
…uwer Rollup of 9 pull requests Successful merges: - rust-lang/rust#157035 (`LivenessValues`: use dedicated enum rather than mutually exclusive `Option`s) - rust-lang/rust#157182 (Restore simpler Encode/Decode impls for u32 and (on 64bit systems) usize) - rust-lang/rust#157310 (rustdoc: Render `impl` restriction) - rust-lang/rust#157070 (Remove `skip_arg` attribute from `Diagnostic` and `Subdiagnostic` proc-macros) - rust-lang/rust#157137 (rustc_target: Use +spe for powerpcspe targets) - rust-lang/rust#157215 (Implement argument-dependent target checking for the `#[repr]` parser) - rust-lang/rust#157235 (additional changes for issue-144595) - rust-lang/rust#157321 (Remove unnecessary arm in `handle_res`) - rust-lang/rust#157324 (Add test for undefined EII static error)
… r=cjgillot Fix malformed transmute handling during mir build Running dataflow const prop optimization on `std::mem::transmute` of mismatched sizes failed the assertion in interpreter and caused ICE. So it's better to not let those transmutations into the interpreter at all Fixes rust-lang/rust#149920
Update cargo submodule 14 commits in fbb61be30e5f9ac3a6ad58e56a5c0f5db2d2b3ef..0b1123a48825309b697312b44fdb64b3df00c958 2026-05-26 15:08:03 +0000 to 2026-06-01 21:20:28 +0000 - chore(deps): update rust crate git2 to 0.21.0 (rust-lang/cargo#17060) - chore(deps): update compatible (rust-lang/cargo#17057) - fix(util): constant type for Redox OS (rust-lang/cargo#17064) - chore(deps): update crate-ci/typos action to v1.47.0 (rust-lang/cargo#17059) - chore(deps): update embarkstudios/cargo-deny-action action to v2.0.20 (rust-lang/cargo#17058) - chore(deps): update cargo-semver-checks to v0.48.0 (rust-lang/cargo#17054) - chore: bump to 0.99.0; update changelog (rust-lang/cargo#17049) - Bump cargo-util-schemas to 0.14.2 (rust-lang/cargo#17048) - feat: Add edition for scripts anytime we mutate the manifest (rust-lang/cargo#17038) - docs: clarify on crate removal post RFC 3660 (rust-lang/cargo#17036) - feat: Add --output-format=json to cargo doc as an unstable option (rust-lang/cargo#17025) - feat(diag): Add the 'cargo::default' group (rust-lang/cargo#17033) - fix(add): Ensure erros are lower case (rust-lang/cargo#17037) - fix(diag): Report summaries for unused_deps (rust-lang/cargo#17034)
…s, r=ChrisDenton Switch the destructors implementation for thread locals on Windows to use FLS ## Summary Switch the thread local **destructors** implementation on Windows to use the _Fiber Local Storage_ APIs, which provide native support for setting a callback to be called on thread termination, replacing the current `tls_callback` symbol-based implementation. _Except for some spellchecking, no LLMs were used to produce code / comments / text in this PR._ ## Current Implementation On Windows, in order to support thread locals with destructors, the standard library uses a special `tls_callback` symbol that is used to call the `destructors::run()` hook on thread termination. This has two downsides: 1. It is not well documented, and seems to cause some problems [1] [2] [3]. 2. It disallows some synchronization operations, as mentioned in [`LocalKey`'s documentation](https://doc.rust-lang.org/std/thread/struct.LocalKey.html#synchronization-in-thread-local-destructors). [1]: rust-lang/rust#144234 [2]: rust-lang/rust#145154 [3]: rust-lang/rust#140798 as an example of point 2, this code, which uses `JoinHandle::join` in a thread local Drop impl, will deadlock on stable: <details> <summary>Join-on-Drop Deadlock Example</summary> ```rust struct JoinOnDrop(Option<JoinHandle<()>>); impl Drop for JoinOnDrop { fn drop(&mut self) { self.0.take().unwrap().join().unwrap(); } } thread_local! { static HANDLE: JoinOnDrop = { let thread = std::thread::spawn(|| { println!("Starting..."); // std::thread::sleep(Duration::from_secs(3)); println!("Done"); }); JoinOnDrop(Some(thread)) }; } fn main() { let thread = std::thread::spawn(|| { HANDLE.with(|_| { println!("Some other thread"); }) }); thread.join().unwrap(); println!("Done"); } ``` </details> ## Proposed Change We can use the `Fls{Alloc,Set,Get,Free}` functions (see https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=102989) to implement the dtor callback needed for thread locals that have a Drop implementation. We allocate a single key, and use its destructor callback to run all the registered destructors when a thread is shutting down. With this implementation, the above code sample will not deadlock (but it still might not be a good idea to do this!). ## Safety and Compatibility We use the common `thread_local` + atomic pattern to only set a single FLS key. The destructor callback is only called when that value is non-zero. Destructors will only run at thread exit: we verify that we are not running in a fiber during the destructors callback. **This means that using fibers (which is very rare) will result in thread locals being leaked**, unless the fiber is converted back to a thread using `ConvertFiberToThread` before thread termination. This is not ideal, but should be OK as destructors are not guaranteed to run, but it needs to be documented. It might be possible for the user to use something like the current `tls_callback` to observe an already-freed thread locals, which is something that can also happen in the current implementation. ~Destructors will only run on the correct thread: Fibers cannot be moved between threads.~ Destructors will only run on the correct thread: the hook uses a `#[thread_local]` list, so fiber movement between threads does not change which which thread executes the destructors. Destructors will only run once: even if the hook is called multiple time, the `#[thread_local]` list is cleared after the first run. Users cannot observe different locals because they are using fibers: because we only use an Fls local marker to trigger the destructors callback, we don't change anything about how users interact with "normal" thread locals and fiber locals. ### DLL Unloading It is possible to build a `cdylib` which uses thread locals and unload it dynamically using `FreeLibrary`. This can cause the OS to call into an unmapped cleanup hook, so we use `atexit` to manually free the special FLS key, which will also trigger the cleanup hook for each registered thread. This is safe because similar to thread shutdown, no user code can ran after this point, and only the destructors of the running thread will run. see `tests/run-make/dynamic-loading-cdylib/load_and_unload.rs`. ## Other Notes The implementation is based on the `key::racy` and `guard::apple` code, because we need a `LazyKey`-like racey static and an `enable` function. While TLS slots are [limited to 1088](https://devblogs.microsoft.com/oldnewthing/20170712-00/?p=96585), FLS slots are currently [limited to 4000](https://devblogs.microsoft.com/windows-music-dev/effectively-removing-the-fls-slot-allocation-limit-in-windows-10/) per process. ### Miri Because miri is aware to the thread local implementation, I also implemented these functions and support for them in the interpreter here: https://github.com/rust-lang/miri/compare/master...ohadravid:miri:windows-fls-support?expand=1 I guess that this will need to be merged before this PR (if this is accepted) - let me know and I'll open that PR as well. ### Targets without `target_thread_local` In `*-gnu` Windows targets, the `target_thread_local` feature is unavailable. We could also change the "key" (non-`target_thread_local`) Windows impl at `library\std\src\sys\thread_local\key\windows.rs` to be based on the Fls functions. I can add it to this PR, or as a separate PR, if you think this is preferable. `Cell` in a `#[thread_local]` is used to store the resulting key, like the other implementations. When `target_thread_local` isn't available, we always fetch the atomic and set the FLS key's value.
This updates the rust-version file to 49b19d32b9f01a5aa606f3bf2e90e6e0aa462c03.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@49b19d3 Filtered ref: 5b4eab9 Upstream diff: rust-lang/rust@c58275e...49b19d3 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 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.
There was a conflict in src/offload/usage (see #2874 and rust-lang/rust#156642), causing the automated pull to fail