Skip to content

Rollup of 14 pull requests - #164026

Closed
JonathanBrouwer wants to merge 35 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-ET4ZZN3
Closed

JonathanBrouwer wants to merge 35 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-ET4ZZN3

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

fmease and others added 30 commits September 11, 2026 18:53
```
error[E0277]: `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
  --> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:34:14
   |
LL |     for _ in closure {}
   |              ^^^^^^^ `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
   |
help: the trait `Iterator` is not implemented for closure `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}`
  --> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19
   |
LL |     let closure = || vec![1u8].into_iter();
   |                   ^^
   = note: required for `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` to implement `IntoIterator`
help: use parentheses to call this closure
   |
LL |     for _ in closure() {}
   |                     ++
```
… old solver and update `incorrect-skip-binder-for-item-bound` test accordingly.
`CanonicalVarValues` is serving two roles. There are the places where
it's a real substitution (e.g. return value of `instantiate`), and
places where it's just a result never used for instantiation (e.g.
`Response` and `inspect::State` and `EvalCtxt`). The latter can just be
`I::GenericArgs`.

Simplifications from this:
- Removes some `var_values.var_values` chains.
- `make_identity` can be inlined into its single caller.
- `CanonicalVarValues::is_identity*` can be moved to methods of
  `Response`.
- `CanonicalVarValues::dummy` is no longer needed.
Similar to the previous commit, but for the old solver.
…r=adwinwhite

Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)

Follow-up to rust-lang#162269. Addresses fmease/rasur#7 (item 6).

<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
…iveness, r=tmiasko

MIR move elimination [3/6]: PreciseLiveness

Depends on rust-lang#163335

This PR implements the lifetime analysis used by the `MoveElimination` pass from rust-lang/rfcs#3943.

`PreciseLiveness` calculates, at a sub-statement granularity, the points in a function where a local requires storage to be allocated. This is more fine-grained than `MaybeStorageLive`, and takes borrows into account.

r? tmiasko
…=Kobzol

fix(bootstrap/darwin): fix rpath for distributed LLD

Closes rust-lang#163947 by mirroring the existing rpath tweak for linux on darwin.

## Concerns

- [ ] Is there an easy way to reliably test the effect of this fix (there doesn't seem to be dist tests for darwin in particular)? I'd love to add one if possible.
…oss35

cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`

On the Linux platform, only `x86` and `x86_64` support `Float128`. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431)
Therefore, for aarch64, the `f128` type corresponds exclusively to `long double`.
In addition, `aarch64` does not overload `getLongDoubleMangling` and `getFloat128Mangling`.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822)
Therefore, `aarch64` on Linux should send `e` instead of `g`.

For Windows and Apple `aarch64`, the `long double` type is 64-bit, so these targets need to be excluded.

The corresponding tests are added.

LLM disclosure: This commit is entirely handwritten.

r? @tgross35
move overflow lint computation into decorator

implements rust-lang#163064 (comment)

r? adwinwhite
…JohnTitor

Updates the expect message library/core/src/time.rs

updates the expect message in library/core/src/time.rs.
Updated to show the expected state instead of what actually happened.

rust-lang#159751
rigid aliases to non-rigid for fully normalized check

otherwise we incorrectly mark rust-lang#163724 / rust-lang#152416 as fixed with the new solver 😅

r? adwinwhite
…-possible, r=adwinwhite

replace `fully_monomorphized` with `cx.typing_env()`

cc rust-lang#163724

reasoning about whether a given `TypingEnv` is correct is non-trivial, so if we've got a context which already provides the correct `TypingEnv`, using that is easier.
Fix debug assert failure in `note_obligation_cause_code_inner`

Applied the recommended fix and turned the crash test into a regression test. Closes rust-lang#139381.

r? lcnr
const-eval: ICE when we hit a non-const fn

We made this a "nice" error solely so we can test miri-unleashed better, but it was never meant to be an error that users can actually get -- just a second line of defense in case there is a bug in our const checking logic. This seems to [cause some confusion](rust-lang#161627 (comment)) so let's make it an ICE when Miri is not unleashed.

This also uncovered that even if `const_precise_live_drops` finds a problem, we still run the code that was found to not be const-safe: rust-lang#163973.

r? @oli-obk
Cc @tmiasko
When mentioning that closure doesn't implement trait, point at closure

```
error[E0277]: `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
  --> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:34:14
   |
LL |     for _ in closure {}
   |              ^^^^^^^ `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
   |
help: the trait `Iterator` is not implemented for closure `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}`
  --> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19
   |
LL |     let closure = || vec![1u8].into_iter();
   |                   ^^
   = note: required for `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` to implement `IntoIterator`
help: use parentheses to call this closure
   |
LL |     for _ in closure() {}
   |                     ++
```
…d, r=Urgau

[rustdoc] Prefer local paths over remote ones when foreign item is locally reexported

This is the last failure from rust-lang#162808:

```
src/std/sys/fs/unix.rs.html:1171: broken link fragment `#method.new` pointing to `core/io/struct.Error.html`
```

`std` reexports `Error` locally, and `alloc` is the one implementing the `Error::new` method. So `std` has both `Error` and `Error::new` locally. So instead of trying to link to `core::Error::new` (which doesn't exist), we first check if we locally reexport `Error` with the `paths` map and use it as a shortcut.

PS: I got annoyed about adding/removing `#[derive(Debug)]` every time so this time I just leave them there. :3

r? @Urgau
cg_llvm: Avoid some explicit casts to `*const c_char`

- Follow-up to rust-lang#163789
---

This is another application of the general principle noted in `rustc_codegen_llvm::ffi`:

> Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side.

For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead.

Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors.

---

A second commit also removes some pointer casts that were completely unnecessary.

There should be no change to compiler output.
…s, r=lcnr

Less `CanonicalVarValues`

It was bugging me that `CanonicalVarValues` is used in two different ways. Here's my attempt to remedy that.

r? @lcnr
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Oct 9, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. F-autodiff `#![feature(autodiff)]` PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Oct 9, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member Author

@bors r+ p=5 force

@rust-bors

rust-bors Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 610b5ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 9, 2026
@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 9, 2026
@rust-bors

rust-bors Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. F-autodiff `#![feature(autodiff)]` PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.