Fix untidy - #10
Closed
yilin0518 wants to merge 1166 commits into
Closed
Fix untidy#10yilin0518 wants to merge 1166 commits into
yilin0518 wants to merge 1166 commits into
Conversation
…ForArrayLengths, r=BoxyUwU Remove unused `StashKey::UnderscoreForArrayLengths` It's no longer ever used for stashing, so the code looking for it is dead. It became dead in rust-lang#141610 when `generic_arg_infer` was stabilized and `[T; _]` became valid. r? @BoxyUwU
rename direct_const_arg! to gca! Also re-export it from `std`, and make most tests `use std::gca;` rather than writing out `core::` every time the macro is called. Part of the design rework discussed in Zulip [#project-const-generics > talkies at last @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/near/620368825) r? @BoxyUwU
…nnethercote Remove `suggestion_for_allocator_api` It's dead code since rust-lang#156882 cc @nia-e
…, r=ShoyuVanilla document `#[rustc_dyn_incompatible_trait]`
…strained-const-args, r=BoxyUwU regression test for unconstrained const args Closes rust-lang#146906
…re-suggestion, r=nnethercote Enhance mutable closure suggestions with as_mut() support This PR changed `can_use_as_ref` to support `as_mut` when `as_ref` is not proper.
Fix Typo in `std::sys::process::unix::unsupported::wait_status` Docs Noticed while collecting data on conditional compilation for potential aliasing (see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Using.20.60build.2Ers.60.20for.20cfg.20aliases.20in.20.60std.60/with/625458363) for details) that this attribute was missing its closing brace. Extremely trivial, might as well fix it!
…, r=lqd Remove `DiagInner::sort_span` It's a field that can be used for sorting diagnostics. By default it is set to the primary span. It's only used for `BorrowckDiagnosticsBuffer`. This commit removes it and adds a `sort_span` to each diagnostic recorded in `BorrowckDiagnosticsBuffer`. This avoids various other pieces of code having to deal with it. r? @lqd
…bit, r=tgross35 Fix flt2dec build on 16-bit targets Closes rust-lang#163158. Fixes build breakage rust-lang#162879 on the two 16-bit targets, `avr-none` and `msp430-none-elf`, by including `target_pointer_width = "16"` in all the cfg attributes for the u32 implementations for bignum and flt2dec.
…t-tests improve simd bitshift tests
…nathanBrouwer Rollup of 12 pull requests Successful merges: - rust-lang#162177 (Properly implement the gpu-kernel ABI for amdgpu) - rust-lang#163168 (std: Update `wasip3` crate dependency) - rust-lang#163179 (Cleanup offload build steps) - rust-lang#163194 (Remove unused `StashKey::UnderscoreForArrayLengths`) - rust-lang#163198 (rename direct_const_arg! to gca!) - rust-lang#163205 (Remove `suggestion_for_allocator_api`) - rust-lang#162497 (document `#[rustc_dyn_incompatible_trait]`) - rust-lang#162702 (regression test for unconstrained const args) - rust-lang#163191 (Enhance mutable closure suggestions with as_mut() support) - rust-lang#163192 (Fix Typo in `std::sys::process::unix::unsupported::wait_status` Docs) - rust-lang#163196 (Remove `DiagInner::sort_span`) - rust-lang#163197 (Fix flt2dec build on 16-bit targets)
Pull from rust-lang/rust
FreeBSD 13.1 had introduced a sched cpu affinity compatibility layer with Linux. 13.0 and even 13.1 being EOL, we can simplify here.
Rename rust-toolchain to rust-toolchain.toml
This reverts commit 95d43bf. Now that closures have field retagging again, we need this MaybeDangling again.
Follow-up to rust-lang#151742.
…nathanBrouwer Rollup of 3 pull requests Successful merges: - rust-lang#161728 (dont lint unused parens on a pattern that came from a macro argument) - rust-lang#161791 (Make dropping an empty BTreeMap free) - rust-lang#163283 (Update expect messages in rust_const_eval)
…fonthey Document platform-specific behavior of `current_exe`, including that Linux can add `" (deleted)"` This documents one other OS-specific behavior that might be surprising to some users. The underlying behavior is documented in for example <https://man7.org/linux/man-pages/man5/proc_pid_exe.5.html>. Rust std docs can't and shouldn't try to cover every single OS quirk but this seems reasonably in line with telling people how to use this function, and with the text above about what happens when the exe has been renamed. This came up in the context of zed-industries/zed#46367 Fixes rust-lang#69343 (by documenting the behavior)
Allow elided ('static) lifetimes in `thread_local!`
with or without a const initializer, on all platforms.
Lifetime elision on functions includes named lifetimes and `'static` in input lifetime positions, so if we give the macro-generated `__rust_std_internal_init_fn` function an argument mentioning `'static`, then elided lifetimes in the return type default to `'static`. This uses `PhantomData<&'static ()>` so that it should probably compile down to nothing (at least in release mode).
Before this change, elided `'static` lifetimes were allowed only with `const` initializers on the "no-threads" and "native" `thread_local!` implementations, not on the "os" implementation, and not with non-`const` initializers.
After this change, they are allowed in all `thread_local!` implementations, with or without a `const` initializer (`A` and `B` both compile on targets with all three `thread_local!` implementations.)
```rs
// Const initializer
std::thread_local!(static A: &str = const { "" });
// Non-const initializer
std::thread_local!(static B: &str = "");
```
| `thread_local!` implementation | `const` initializer (`A`) | non-`const` initializer (`B`) |
| ------------- | ------------- | ---- |
| no-threads (e.g. `x86_64-unknown-uefi`) | ✅️ | ❌️ -> ✅️ |
| `target_thread_local` (e.g. `x86_64-unknown-linux-gnu`) | ✅️ | ❌️ -> ✅️ |
| os (e.g. `x86_64-pc-windows-gnu`) | ❌️ -> ✅️ | ❌️ -> ✅️ |
An alternative implementation that would only fix the inconsistency between targets, but not add support for elision with non-`const` initializers, would be to do this same thing, but only on the `os` implementation, and only if the initializer is `const` (i.e. split const initializers to a different macro arm; currently const and non-const initializers generate the same code under the `os` `thread_local!` implementation).
Fixes rust-lang#159538
Fixes rust-lang#159640 (assuming the non-`const`-initializer part of this PR is not removed)
…info, r=beetrees hir_typeck: simplify `upvar::determine_capture_info` impl
Document `rustc_abi::VariantLayout` Follow-up to rust-lang#151742. cc @saethlin @moulins @RalfJung as you were involved with the original PR
…, r=clarfonthey Stabilize SyncView This is a stabilization PR for rust-lang#98407. Closes rust-lang#98407.
Option, Result: not all arguments passed to map_or are eagerly evaluated The 2nd argument is a closure, which is lazily evaluated. I this this text was copied from other methods like `ok_or` that only have a single argument.
…nathanBrouwer Rollup of 6 pull requests Successful merges: - rust-lang#150824 (Document platform-specific behavior of `current_exe`, including that Linux can add `" (deleted)"`) - rust-lang#159564 (Allow elided ('static) lifetimes in `thread_local!`) - rust-lang#163026 (hir_typeck: simplify `upvar::determine_capture_info` impl) - rust-lang#163256 (Document `rustc_abi::VariantLayout`) - rust-lang#163366 (Stabilize SyncView) - rust-lang#163376 (Option, Result: not all arguments passed to map_or are eagerly evaluated)
…fonthey Guarantee 8 bytes of alignment of RawWakerVTable This is similar to an earlier PR I made for `Thread::into_raw`: rust-lang#143859. When using `AtomicPtr` for synchronization it's incredibly useful when you've got a couple bits you can stuff metadata in. By guaranteeing that `RawWakerVTable` is aligned to 8 bytes everyone can use the bottom 3 bits to signal other things, such as a critical section, etc. In particular, this can be used to portably implement an `AtomicWaker` which is always two pointers in size, no more. On almost all platforms the align is already 8 bytes, and on other platforms it might cause an infinitesimal increase in size. This guarantee is thus very useful and costs us essentially nothing. --- r? libs-api Like last time since this adds a guarantee this probably needs a FCP.
Update books ## rust-lang/reference 2 commits in e24eecf97b0c9a6dbac67191098204dc8a190aaa..4245282b97496585e73862b966d639cbb553bd6c 2026-09-15 19:41:20 UTC to 2026-09-15 17:32:28 UTC - Glossary: add entry and examples for `n-zst` (rust-lang/reference#2357) - Document RISC-V d and f extensions (rust-lang/reference#2355) ## rust-lang/rust-by-example 4 commits in 15308f3e951814ef3475d2b58f48276e6b17b9af..af5ef7024e88587aa3be244422f6365e86c50e85 2026-09-15 14:15:08 UTC to 2026-09-15 14:13:27 UTC - Better formatting (rust-lang/rust-by-example#2024) - Add an example of accessing Union elements (unsafe) (rust-lang/rust-by-example#2027) - Improve linked list example (rust-lang/rust-by-example#2022) - Fix typo in TRANSLATING.md (rust-lang/rust-by-example#2028)
Rollup of 2 pull requests Successful merges: - rust-lang#158186 (Guarantee 8 bytes of alignment of RawWakerVTable) - rust-lang#163122 (Update books)
…ratt Fix docs in core::slice - Add a comma after the conditional clause in `split_at_checked` and `split_at_mut_checked` - "equals to" -> "equals" in `swap`
This was missing in 4eb7bb3
…ejrs Fix link to the allocator-ext feature tracking issue In 4eb7bb3 the file was renamed from allocator-api to allocator-ext but the relevant tracking issue was not updated.
…, r=clubby789 compiletest: stream output of executor process when --no-capture is set LLM Disclosure: LLM was used to understand the issue and relevant parts of the codebase. It also suggested the fix which was thoroughly verified and understood before applying. Fixes rust-lang#128565 On triaging the issue, it was found that: - This occurs because the stdout and stderr of the child(executor) process in which the run-make test runs are piped to parent (compiletest) process. So they are not be dumped to the terminal till the process is complete. (in `src/tools/compiletest/src/runtest/run_make.rs`). ``` let mut cmd = Command::new(&recipe_bin); cmd.current_dir(&rmake_out_dir) .stdout(Stdio::piped()) .stderr(Stdio::piped()) ``` - But this is not required in the case where we want to run a test with `--no-capture`. - So a fix would be to use `Stdio:inherit()` and not reading the stdout of the executor process using `self.read2_abbreviated(proc); `when using the `--no-capture` flag . ``` if self.config.capture { cmd.stdout(Stdio::piped()).stderr(Stdio::piped()); } else { cmd.stdout(Stdio::inherit()).stderr(Stdio::inherit()); } ``` This change ensures that the stdout and stderr of the executor process are directly streamed to the bootstrap process, which already prints them as they arrive when using the `--no-capture` flag . ( in `src/bootstrap/src/utils/render_tests.rs`) ``` let Some(mut streaming_command) = cmd.stream_capture_stdout(&builder.config.exec_ctx) else { return true; }; let renderer = Renderer::new(streaming_command.stdout.take().unwrap(), builder, record_failed_tests); if stream { renderer.stream_all(); } else { renderer.render_all(); } ```
…nia-e Use StaticAllocator in more places See: [#t-libs/wg-allocators > StaticAllocator @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/197181-t-libs.2Fwg-allocators/topic/StaticAllocator/near/626634547) r? @nia-e
Remove some code duplication in coerce_shared.rs Saw this while working on something else.
…nathanBrouwer Rollup of 3 pull requests Successful merges: - rust-lang#162714 (compiletest: stream output of executor process when --no-capture is set) - rust-lang#163394 (Use StaticAllocator in more places) - rust-lang#162672 (Remove some code duplication in coerce_shared.rs)
Remove rustc_hir's attribute re-exports Followup to rust-lang#160336, see also rust-lang#163170, rust-lang#163207 and rust-lang/rust-clippy/pull/17714 Very minor touchups here and there, nothing involving code changes. r? @JonathanBrouwer
…crum Update mailmap for Clar Fon Guess I should probably do this.
use is_some_and / is_none_or in a few more places IMO that makes the code more readable. Clippy also lints this by default these days, but we don't run that lint on the compiler it seems.
…nathanBrouwer Rollup of 3 pull requests Successful merges: - rust-lang#163250 (Remove rustc_hir's attribute re-exports) - rust-lang#163329 (Update mailmap for Clar Fon) - rust-lang#163378 (use is_some_and / is_none_or in a few more places)
* Implement forced keywords * Allow any identifier to be forced as a keyword even if not reserved
Implement forced keywords (`k#`) Part of rust-lang#153839. CC @dianne Introduces a new token kind to Rust >=2021 that looks like `k#ident` and that is called *forced keyword (identifier)*. This is gated behind a new unstable feature called `forced_keywords`. This is backed by [compiler MCP 945](rust-lang/compiler-team#945). ~~The `ident` in `k#ident` *must* be a keyword (from any edition) or a weak/contextual keyword for the token to be valid.~~ The `ident` in `k#ident` needn't be a keyword to be lexically valid (CC rust-lang#161775 (comment)). --- What **won't** be done in this PR: 1. implementing forced keyword lifetimes (`'k#static`) 2. migrating away from built-in syntax `builtin # $ident($($tt)*)` / introducing `k#`-exclusive (weak) keywords * that'll be done in PR rust-lang#162232 instead 3. allowing the user to force edition-dependent & context-dependent keywords to be keywords * re. edition-dependent: forcing them to be keywords even in editions where they're usually not a (strong) keyword (today, that only affects `gen` anyway IINM) * re. context-dependent: E.g., `union` is only "active" if it's followed by a non-reserved identifier and under this PR the same rules apply to `k#union` even though that's not necessary; changing it would result in better diagnostics (e.g., for `k#union struct {}`: `` error: expected item, found `k#union` `` => `` expected identifier, found keyword `struct` ``) and maybe also allow for disambiguation for other context-dependent keywords 4. extending the `proc_macro::Ident` API to allow users to programmatically create forced keywords (might never be added) <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
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
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 PR replace
// ignore-tidy-undocumented-unsafewith concrete safety comments. Every// ignore-tidy-undocumented-unsafeinalloc::stris checked. This PR only contains a file for ease of review.