Sync-New - #8
Merged
Merged
Sync-New#8
Conversation
Blindspot22
commented
Aug 27, 2026
Blindspot22
commented
Owner
- I did not use an LLM to create a change in this PR.
- I used an LLM to create a change in this PR, and I have explained below how it was used.
Custom allocators do not get noalias after all
Before, LargeDataThreshold was only set via `LLVMRustCreateTargetMachine`. When LTO is enabled, this information is required to be passed into the generated LLVM module IR files since the LTO linker spins up its own TargetMachine and otherwise has no knowledge of the LargeDataThreshold. Currently, `-Z large-data-threshold` has no affect at all when compiling with LTO. This commit makes sure that if `-Z large-data-threshold` is passed and not 0, it is preserved and stored into the generated LLVM IR.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@5c156cd. Created using https://github.com/rust-lang/josh-sync. r? @ghost
make `pad_i32` of `PassMode::cast` an integer
so that we can specify more than one i32 of padding. This PR only adds the functionality but does not yet use it: there should be no functional changes.
This is needed for the ABI of `Complex<{ float }>` on 32-bit powerpc. Other mechanisms, e.g. using `PassMode::prefixed` don't appear to work.
More discussion is in [#t-compiler/help > power complex abi](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/power.20complex.20abi/with/613294420).
…rouwer Remove `From<!> for T` *reservation* impl This PR removes the `<T> From<!> for T` *reservation* implementation added in #62661 and tracked in #64715 and #64631. The reservation impl in question was added in order to reserve some space for adding the following impl: ```rust impl<T> From<!> for T { fn from(never: !) -> T { never } } ``` It is meant to prevent users from writing *some* impls that would overlap if the `From<!> for T` impl is to be added. This requires T-types FCP. Below is my proposal and necessary context: ## The reservation impl is not sufficient The reservation impl prevents one from assuming that `From<!> for T` is not implemented making the following [not compile](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=220e375c77db9a88c360230283f888cb): ```rust struct LocalType; trait SomeTrait { } impl<T: From<!>> SomeTrait for T { } impl SomeTrait for LocalType { } ``` However, it does not prevent *all* implementation that would overlap given `From<!> for T`. Namely, `From<!> for T` would overlap with the following impls, all of which are currently permitted (and exist): ```rust // T for T identity impl in `core` impl<T> From<T> for T { ... } // Various T->wrapper of T impls present in both the standard library, // and in external crates impl<T> From<T> for W<T> { ... } // !->Local is also allowed impl From<!> for Local {} ``` Also note that the reservation impl only exists for `From<!>`, but not for `From<Infallible>`, so even the impls that the reservation impl is meant to forbid, are currently allowed through `Infallible` anyway (we are planning to make `Infallible` a type alias to `!` at the same time as stabilizing `!`). ## Motivation for `From<!> for T` impl It is surprisingly hard to find the original motivation for `From<!> for T` impl or the reservation impl, other than "people vaguely think that all types should implement `From<!>`, since there is never-to-any coercion". One use-case seems to be "calling infallible function in a fallible one, and unwrapping `Result<_, !>` with `?`". However, nowdays it is trivial to unwrap the result safely without `?`: ```rust let Ok(owo) = infallible_function(); ``` Another use-case that I've seen [mentioned](#62661 (comment)) is "fallible function with a set error, taking an infallible function": ```rust fn try_from<T>(t: T) -> Result<Meow, MyError> where Meow: TryFrom<T>, <Meow as TryFrom<T>>::Error: Into<MyError> { ... } ``` With such definition, you can't pass `Meow` into `try_from`, because `MyError: From<Infallible>` doesn't hold. This is more unfortunate, but it's not clear how widespread this problem is and how bad the workarounds would be. If a function expects `impl FnOnce(...) -> Result<...>`, it should be trivial to coerce the `!` error to an appropriate type. With other trait bounds (like in the example above) it could be solved by adding a custom impl for your specific error type (annoying, but workable). Certaintly this doesn't feel like a big roadblock to me. (let me know if you know more prior art on this) ## There is no clear path for adding `From<!> for T` impl Adding `From<!> for T` seems... hard... and hard to argue for. It would require ignoring overlap with a *bunch* of impls (as described above) and would also require low priority impls (to avoid inference failures in cases where previously the only applicable impl was the identity one, so adding `From<!>` makes "one impl rule" not apply). The [tracking issue](#64715) says: > The precise mechanism to permit us to add the `From<!> for T` impl is not yet clear. The current "plan of record" is to extend the ["marker trait mechanism"](#29864) to accommodate the idea of impls whose entire body consists of unreachable methods and to permit overlap. Considering "traits with all methods having arguments of uninhabited types" as marker traits is technically possible (I think?), but feels like a bit of a stretch. Making overlap check consider if all trait functions take arguments which are uninhabited (known to be uninhabited *in the current context*) seems like a big complication, especially considering how `From<T>` would not be a marker trait in the general case — only `From<!>`/`From<OtherUninhabitedTypes>` would be (also that requires attaching the overlap check to some context from which we can check if a type is publically uninhabited, which can also lead to situations where impl `A` overlaps with impl `B`, but impl `B` doesn't overlap with impl `A`[^1]). Allowing overlap with arbitrary user impls also is likely to cause unforcene issues in my opinion. [^1]: i.e. in the context of impl `A` a certain type is not known to be uninhabited, and thus the overlap between impls should not be allowed. at the same time in the context of impl `B` same type might be known to be uninhabited, allowing the overlap. ## The reservation impl causes problems for the never type stabilization Because the reservation impl reserves space for `From<!> for T`, but not for `From<Infallible> for T`, making `Infallible` an alias for `!` makes some code fail to compile. See #155924: > 3. standard library contains a [reservation impl](https://doc.rust-lang.org/1.94.0/src/core/convert/mod.rs.html#802-806), which forbids [certain](#64715) `From<!>` impls. After making `Infallible = !`, this reservation impl can conflict with existing implementations for `Infallible` - This breaks 14 crates total (including reverse-dependencies of broken crates) Given that both keeping the reservation impl (while making `Infallible = !`) and making the reservation a proper impl break code, we should decide which path we want to pursue before stabilizing the never type (and making `Infallible = !`). ## Proposal After trying to add `From<!> for T` as a proper impl, I'm not convinced that it's worth the complexity and messiness of allowing such widespread overlap (with user defined impls too!). **As such, I propose to remove the reservation impl**, to prevent unnecessary breakage from its combination with making `Infallible = !`, as described above. ## Alternatives - Add proper `impl<T> From<!> for T`, accepting the breakage, overlap, and the complexity. - I'm not sure how feasible this is, after trying to do this approach, it doesn't feel right - Keep the reservation impl / add the reservation impl `From<Infallible> for T` formally accepting the breakage of that, with the hopes that we can still add `impl<T> From<!> for T` in the future - This is the most breaking of the option, as it breaks code that depends on `From<Infallible> for T` not existing, *and* expects future breakage when adding `impl<T> From<!> for T` - It is unlikely that adding `impl<T> From<!> for T` in the future will be much easier than right now ----- Closes #64715 r? types I'll remove the `rustc_reservation_impl` attribute in a separate PR (cc #64631).
bootstrap: Rename `Build` to `Session` - Follow-up to #161277 --- Having separate types named `Build` and `Builder` is quite confusing, especially since *build* by itself isn't a very informative name in the context of a build system. This PR therefore performs the change suggested in #161277 (comment), renaming `Build` to `Session`. While *session* is not exactly the most descriptive name either, it at least has the virtue of being clearly distinct from *builder*. That should be helpful when trying to clarify the different roles of the two types. There should be no change to bootstrap behaviour.
…ochenkov delegation: add tests for delegations to inherent impls Second part of #160505, for more convenient reviewing. Part of #118212. r? @petrochenkov
Clarify token cursor behaviour The meaning of `TokenTreeCursor::index` is context-dependent: in the innermost (current) `TokenTreeCursor` it points to the next token tree, but in all the other (stack) `TokenTreeCursor`s it points to the current token tree. This makes the meanings of "current", "next", and "look_ahead" confusing for it and for `TokenCursor`. This commit clarifies things by adjusting the stack `TokenTreeCursor`s to also point to the next token tree, and by improving various comments. The commit also renames `TokenCursor::next` as `TokenCursor::next_and_bump` for consistency with everything else: `next` means "get the next thing" and `bump` means "advance the cursor", and this operation does both. r? @Kobzol
Add codegen test for Vec::clear lowering to an unconditional store Closes #45459
The essential problem is that, with this table: ```text one | ----| a | b | c a | b | a | b a | ``` And this logic: ```rust let too_many_pipes = divider_count > expected_cells + 1; ``` `expected_cells + 1` winds up as 2, so you get this warning: ```text error: unused content after last table cell --> $DIR/invalid_markdown_table.rs:81:14 | LL | //! a | b | c | ^^^^^^ this content is discarded error: unused content after last table cell --> $DIR/invalid_markdown_table.rs:83:14 | LL | //! a | b | | ^^^^ this content is discarded error: unused content after last table cell --> $DIR/invalid_markdown_table.rs:85:14 | LL | //! a | b | ^^ this content is discarded ``` We really want our warning to give the suggest-escaping flow, like this: ```text error: table row has too many columns --> $DIR/invalid_markdown_table.rs:81:13 | LL | //! a | b | c | ^ any content after this column divider is discarded | = help: to escape `|` characters in tables, add a `\` before them like `\|` error: table row has too many columns --> $DIR/invalid_markdown_table.rs:83:13 | LL | //! a | b | | ^ any content after this column divider is discarded | = help: to escape `|` characters in tables, add a `\` before them like `\|` error: unused content after last table cell --> $DIR/invalid_markdown_table.rs:85:14 | LL | //! a | b | ^^ this content is discarded ``` By only scanning the text between the end of the last cell and the row, instead of doing the entire row, we don't have to re-implement as much of pulldown-cmark's logic.
…uwer Rollup of 7 pull requests Successful merges: - #161648 (`rust-analyzer` subtree update) - #160132 (make `pad_i32` of `PassMode::cast` an integer) - #160705 (Remove `From<!> for T` *reservation* impl) - #161600 (bootstrap: Rename `Build` to `Session`) - #161665 (delegation: add tests for delegations to inherent impls) - #161637 (Clarify token cursor behaviour) - #161653 (Add codegen test for Vec::clear lowering to an unconditional store)
The file path was changed in af4c79b. Fix the link, and use a specific commit so it doesn't break accidentally future.
Alloc `String::retain` optimization Hi again! This uses the exact same algorithm as my other PR: #149784 Technically it should improve performance for `String::retain` too, But let's see what bors thinks.
std::process: fix UEFI ExitStatus::code() silent truncation of error … …codes UEFI status codes are usize-wide with the high bit set for errors (e.g. DEVICE_ERROR is 0x8000000000000007 on 64-bit). the previous `as i32` cast silently dropped the upper bits, losing all error information. stripping the error high bit to extract the error number and negating it, so errors (negative) are distinguishable from success/warning codes (non-negative).
Deny #[inline] on EII declarations
Rename dlltool helper function It doesn't check for MinGW toolchain (`windows-gnu` or `windows-gnullvm`), but `windows-gnu` only. All the callsites use that helper to decide whether dlltool should be used. r? @bjorn3
Tidy: show todo reason when lint fails (and fix the lint's tidy allow statement which was weird and broken...) r? @WaffleLapkin > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
Add regression test for generic inference Fixes #120922. This PR tests the crash mentioned in the issue. The reduction was made with `treereduce` and it was quite drastic. This code causes the same ICE as #120922 on 1.76, 1.77 and 1.78. 1.79 appears to fix it, and it doesn't cause ICE on stable either. I couldn't figure out a good name for the test file so I just used the issue since there were others already doing that. But I could change it if there's a better name for it. EDIT: I saw that tidy didn't like the test name, so I changed it to please it. But like I said, I couldn't think of a good name, so I'm open to suggestions.
Fix long type on diagnostics for conditionally implemented traits Fixes #161439. This PR adds a short_string where it seemed to be missing according to the issue and the code surroundings. The test for it used for base the test from #158494, but with different compiler flags. Thanks @philss @brunojabs
Fix doc link to pointer::addr Remove some backticks that break some doc links on the `Ord`/`PartialOrd` impls for `*const T`
Rollup of 5 pull requests Successful merges: - #159502 (Enhance suggestions for unresolved links with typos path) - #161052 (Add regression test for generic inference) - #161210 (Improve missing extern crate diagnostics in Rust 2015) - #161818 (Fix long type on diagnostics for conditionally implemented traits) - #161839 (Fix doc link to pointer::addr)
``` warning: explicit `package.readme` can be inferred --> compiler/rustc_thread_pool/Cargo.toml:11:1 | 11 | readme = "README.md" | ^^^^^^^^^^^^^^^^^^^^ | = note: `cargo::manual_readme` is set to `warn` by default help: consider removing `package.readme` warning: `rustc_thread_pool` (manifest) generated 1 warning ``` See <https://triage.rust-lang.org/gha-logs/rust-lang/rust/98030530980#L2026-08-26T03:05:00.5401170Z-L2026-08-26T03:05:00.5402963Z>
``` warning: unused dependency `unified-diff` --> src/tools/compiletest/Cargo.toml:37:1 | 37 | unified-diff = "0.2.1" | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `cargo::unused_dependencies` is set to `warn` by default help: consider removing the dependency on `unified-diff` warning: `compiletest` (manifest) generated 1 warning ``` See <https://triage.rust-lang.org/gha-logs/rust-lang/rust/98030530980#L2026-08-26T03:05:07.8912904Z-L2026-08-26T03:05:07.8915112Z>
``` warning: binary `rustdoc_tool_binary` should have a kebab-case name | 1 | /checkout/obj/build/x86_64-unknown-linux-gnu/bootstrap-tools/.../rustdoc_tool_binary | ^^^^^^^^^^^^^^^^^^^ | = note: `cargo::non_kebab_case_bins` is set to `warn` by default help: to change the binary name to `rustdoc-tool-binary`, convert `bin.name` --> src/tools/rustdoc/Cargo.toml:10:8 | 10 - name = "rustdoc_tool_binary" 10 + name = "rustdoc-tool-binary" | warning: `rustdoc-tool` (manifest) generated 1 warning ``` See <https://triage.rust-lang.org/gha-logs/rust-lang/rust/98030530980#L2026-08-26T03:05:00.5389265Z-L2026-08-26T03:05:00.5392627Z>
Add SVE-accelerated Vec::retain_mut for aarch64 The PR adds SVE support for specified width types(8, 16, 32 and 64 bits) in `Vec::retain_mut`. Due to [pointer provenance being stripped by intrinsics](https://rust-lang.zulipchat.com/#narrow/channel/208962-t-libs.2Fstdarch/topic/MaybeUninit.20lane.20variants.20for.20vector.20data-movement.20intrinsic/with/615526760)) here it has to use inline asm instead of sve intrinsics. ## 1. retain half (ns/iter) | Elements | u32 SVE | u32 scalar | Change | u64 SVE | u64 scalar | Change | |---|---|---|---|---|---|---| | 4 | 10.32 | 12.36 | / | 10.25 | 11.83 | / | | 8 | 12.93 | 15.08 | / | 13.40 | 14.74 | / | | 16 | 18.66 | 19.46 | / | 19.08 | 18.89 | / | | 32 | 31.84 | 31.12 |/ | 31.78 | 31.26 | / | | 64 | 32.99 | 59.17 | **-44.2%** | 59.86 | 59.44 | / | | 1,000 | 471.51 | 811.71 | **-41.9%** | 820.98 | 827.16 | / | | 10,000 | 4,660 | 7,990 | **-41.7%** | 5,836 | 8,242 | **-29.2%** | | 100,000 | 46,414 | 79,608 | **-41.7%** | 57,561 | 82,861 | **-30.5%** | ## 2. retain whole | Elements | u32 SVE | u32 scalar | Change | u64 SVE | u64 scalar | Change | |---|---|---|---|---|---|---| | 4 | 3.46 | 3.11 | / | 3.45 | 3.45 | / | | 8 | 4.90 | 4.49 | / | 4.83 | 6.22 | / | | 16 | 8.44 | 8.14 | / | 8.44 | 11.74 | / | | 32 | 15.83 | 15.51 | / | 15.83 | 22.79 | / | | 64 | 21.57 | 30.66 | **-29.6%** | 30.72 | 44.89 | / | | 1,000 | 358.53 | 483.33 | **-25.8%** | 469.18 | 696.43 | / | | 10,000 | 3,127 | 4,745 | **-34.1%** | 5,082 | 6,912 | **-26.5%** | | 100,000 | 32,509 | 49,501 | **-34.3%** | 49,484 | 79,749 | **-38.0%** | r? @Amanieu
interpret: ensure that calls via no-unwind ABIs do not unwind According to our [ABI docs](https://doc.rust-lang.org/nightly/std/primitive.fn.html#abi-compatibility), programs like this are okay: ```rust extern "C-unwind" fn does_not_unwind_but_could() {} fn main() { let f: extern "C-unwind" fn() = does_not_unwind_but_could; let f: extern "C" fn() = unsafe { std::mem::transmute(f) }; f(); } ``` So let's add a test for that. And also, let's adjust the checks in Miri's shims accordingly (see `src/tools/miri/src/shims/sig.rs`). We used to reject calls to functions that *might* unwind with a signature that does not allow unwinding, even if no unwinding occurred. I don't think we have an actual example of a potentially-unwinding shim with an ABI that has a compatible ABI that does not allow unwinding ("C-unwind" and "C"), so we can't add a test for this.
… r=adwinwhite borrowck: Normalize non-rigid aliases in NLL type relating Fixes #160652 With `-Znext-solver=globally`, yielding from an `impl Iterator` without an explicit `Item` bound ICEs in borrowck. The coroutine defining type returned by `type_of` is unnormalized, so its yield type remains `<impl Iterator as Iterator>::Item`. Skipping normalization propagates that non-rigid alias into both MIR's `CoroutineInfo` and borrowck's `UniversalRegions`; NLL type relating then hits its invariant that non-rigid aliases must already have been normalized. Deeply normalize the instantiated defining type when MIR construction creates `CoroutineInfo` and when borrowck reconstructs `DefiningTy`. That makes the coroutine yield and resume types rigid before NLL compares them. This is intentionally gated to the next solver. The old solver keeps the existing skip-normalization path because deeply normalizing defining types there causes regressions.
Assorted bootstrap config refactors (part 1/N) Related to my current LLVM refactoring in bootstrap, and some of it was unblocked by it. The goal is to remove as much command execution and I/O (mainly network I/O) from config parsing, and turn the "impure derived computation" part to `Session` instead. Eventually this will require restructuring `download-ci-rustc`. As a side note, combining `--print sysroot` and `--print target-libdir`, plus one other cleanup, made cache-primed `./x build compiler` ~40ms faster for me locally. The first commit removed duplicated fields between `Session` and `Config`. It cheats a bit, I implemented `Deref` to get from `Session` to `Config`, to avoid having to update 100+ use sites across bootstrap. But I think it's fine, because it is read only, and adding `.config` everywhere doesn't really add much. CC @Zalathar r? jieyouxu
Change `is_eligible_for_coverage` from a hook to a query - Inspired by seeing #161808 add more eligibility conditions --- This check is called from a few different places when coverage is enabled, so we should probably let the query system take care of memoizing results and tracking dependencies. (It was made a hook in #122322, but I didn't have strong reasons for making it a hook and not a query, other than it being relatively small and simple.) There should be no user-visible change to compiler behaviour.
chore: fix cargo lints Fixes two cargo lint erros found during <#161789 (comment)>. See each commit message respectively for details.
rustdoc: fix lint `cargo::non_kebab_case_bins` ``` warning: binary `rustdoc_tool_binary` should have a kebab-case name | 1 | /checkout/obj/build/x86_64-unknown-linux-gnu/bootstrap-tools/.../rustdoc_tool_binary | ^^^^^^^^^^^^^^^^^^^ | = note: `cargo::non_kebab_case_bins` is set to `warn` by default help: to change the binary name to `rustdoc-tool-binary`, convert `bin.name` --> src/tools/rustdoc/Cargo.toml:10:8 | 10 - name = "rustdoc_tool_binary" 10 + name = "rustdoc-tool-binary" | warning: `rustdoc-tool` (manifest) generated 1 warning ``` See <https://triage.rust-lang.org/gha-logs/rust-lang/rust/98030530980#L2026-08-26T03:05:00.5389265Z-L2026-08-26T03:05:00.5392627Z> This was found in <#161789>.
Rollup of 7 pull requests Successful merges: - #161034 (Add SVE-accelerated Vec::retain_mut for aarch64) - #161628 (interpret: ensure that calls via no-unwind ABIs do not unwind) - #161012 (borrowck: Normalize non-rigid aliases in NLL type relating) - #161691 (Assorted bootstrap config refactors (part 1/N)) - #161813 (Change `is_eligible_for_coverage` from a hook to a query) - #161842 (chore: fix cargo lints) - #161843 (rustdoc: fix lint `cargo::non_kebab_case_bins`)
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.