Skip to content

Automated pull from upstream HEAD#2452

Closed
ferrocene-automations[bot] wants to merge 668 commits into
mainfrom
automation/pull-upstream-HEAD/y5r2fo5j
Closed

Automated pull from upstream HEAD#2452
ferrocene-automations[bot] wants to merge 668 commits into
mainfrom
automation/pull-upstream-HEAD/y5r2fo5j

Conversation

@ferrocene-automations

Copy link
Copy Markdown

⚠️ The automation reported these warnings: ⚠️

  • There are merge conflicts in this PR. Merge conflict markers have been committed.
  • Couldn't regenerate the x.py completions. Please run ./x run generate-completions after fixing the merge conflicts.
  • Couldn't regenerate the x.py help file. Please run ./x run generate-help after fixing the merge conflicts.
  • Couldn't regenerate the symbol report. Please run './x test ferrocene/doc/symbol-report.csv --bless' after fixing the conflicts.

This PR pulls the following changes from the upstream repository:

ChayimFriedman2 and others added 30 commits July 3, 2026 08:06
fix: Fix handling of params of coroutine fns
update `FIXME(static_mut_refs)` comment to say: use raw pointers instead
of references.
find_attr_range_with_source assumes that all syntax nodes came from
the original user source code. This isn't true when we do speculative
completion of macros: we create additional SyntaxNode values.

Ensure that completion is defensive against created syntax nodes, and
add a unit test.

AI disclosure: Used GPT-5.5 to help implement.
and just always show diffs by default.
not sure why you'd want to hide them.
fix: Crash on completion inside macros
This is more robust then assuming it's in Program Files. We still fallback to Program Files as a last resort.
Because we use `ThinVec` rather than `Vec` almost everywhere else in the
AST.
Because we use `ThinVec` rather than `Vec` almost everywhere else in the
AST.
With comparing `sub_unification_table_root_var` you can have an arbitraty
long chain of subtyping relatinships, i.e. a <: b :> c <: d :> e ...,
where all a/b/c/d/e/... get the same sub root var. So it's not necessarily
true that there exists a type that is directly sub/super of the types
compared via `sub_unification_table_root_var`.
The unstable attribute on Read::read_le and Read::read_be pointed to
the implementation PR rather than the tracking issue, so the docs on
doc.rust-lang.org linked to the wrong page.
The docs stated that try_with will return an AccessError when the key
has been destroyed. This is not guaranteed: on some platforms, TLS
slots can be re-initialized during destruction, so the destroyed state
cannot always be observed. Change 'will' to 'may' to accurately reflect
the best-effort nature of the check.
…026-07

Update date-check markers for July 2026
JonathanBrouwer and others added 23 commits July 7, 2026 22:26
Enable Enzyme on x86_64-apple

Enable Enzyme for x86_64-apple

similar PR: rust-lang/rust#157240

r? @ZuseZ4
std: unconditionally use `preadv`/`pwritev` on AArch64 macOS

The stars happened to line up perfectly: macOS 11.0 was the first version to support ARM, and also the first version with `preadv`/`pwritev`. Thus we don't need to use weak linkage if the target is `aarch64-apple-darwin`.
disallow `extern "custom"` on wasm and spirv targets

tracking issue: rust-lang/rust#140829

I'm not sure if we should exclude any other architectures? The GPU ones are a bit suspect maybe?
…apping, r=petrochenkov

delegation: support mapping of all arguments with `Self` type

This PR supports applying target expression to arguments of `Self` type.
That the first part of this feature which touches AST -> HIR lowering only and allows lowering of delegation's block several times when there are no definitions inside.
The second part will adjust typeck so we can apply adjustments to all mapped arguments as to the first argument of delegation. This should also eventually weak the condition of argument mapping allowing `Box<Self>`, `Arc<Self>`, etc.

Part of rust-lang/rust#118212.
r? @petrochenkov
Rename some `body_id` to `body_def_id`

Since body IDs and item IDs are distinct things, try to use names that do not conflate them. `body_def_id` is a little easier to read as "body-owning definition ID" whereas `body_id` is hard not to just read as "body ID".

Related: rust-lang/rust#158611 - I noticed this afterwards. I suspect that `FnCtxt` ought to keep `body_def_id` but maybe add `body_id: BodyId` in addition.
Fixes for QNX SDP 8

This PR contains libstd fixes so libstd can be build for QNX SDP 8.

It requires patches to libc-0.2 and cc-rs. The cc-rs patch [was merged]([rust-lang/cc-rs#1775](rust-lang/cc-rs#1775)) already. I have a patch for libc-1.0 [here](rust-lang/libc#5241) which will need backporting to libc-0.2 once merged.

With these in place, I was able to remotely `test tests/ui library/std library/alloc library/core` for `x86_64-pc-qnx` using a remote-test-server running on QNX SDP 8.0's QEMU BSP image. The only tests that failed were the two `tests/ui/codegen/huge-stacks.rs` tests, and I did not have enough RAM to run them.
…r=aapoalas

Clarify that `LocalKey::try_with` may return `AccessError`

The docs for `LocalKey::try_with` state that the function *will* return an `AccessError` when the key has been destroyed. That's not actually guaranteed:

- `LocalKey::with` uses `try_with` internally and its docs explicitly acknowledge that it does not always panic when the destructor has run. If `try_with` really did detect every destroyed thread-local, `with` could always panic.
- The top-level `LocalKey` docs already note: "On all platforms it's possible for TLS to re-initialize other TLS slots during destruction."

Change *will* to *may* to accurately reflect the best-effort nature of the destroyed-key check.

Closes rust-lang/rust#157889

@rustbot label +A-docs
Rewrite safety requirements for `Allocator` impls

This PR supersedes rust-lang/rust#156544.

cc rust-lang/rust#157428, rust-lang/rust#156920

cc @nia-e

r? @Amanieu (reviewer of rust-lang/rust#156544)

I define the concept of "equivalent allocators", in order to be able to talk about cloning allocators, and to give commonsense guarantees about stdlib `Allocator` impls.

I define the concept of "invalidating a memory block" in order to be able to talk about users not being allowed to use a block of allocated memory after its allocator is "gone".

An `Allocator` implementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires.

Mutation of an `Allocator` should sensibly be allowed to invalidate its allocations. For example, the `bumpalo` crates has a `Bump::reset` method that takes `&mut self` and invalidates all past allocations. Accesses via `&` still must not invalidate past allocations since, for example, `Box` provides `&` access to the allocator.

I still had the "allocator destructor" clause as a separate clause from the `&mut` clause, to avoid questions about whether drop glue of types that don't implement `Drop` but have fields that implement `Drop` counts as creating a `&mut` to the whole thing.

The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for `Box::into_pin` and `{Rc, Arc}::pin` to be sound. (Those methods have an `A: 'static` bound to prevent allocating via a `&MyAllocator` and then running `MyAllocator`'s destructor.)
…ycat

rustdoc: Fix sidebar heading order

Makes sidebar heading order match the order of the headings in the main content.
Fix typetree generation for differentiated functions

Further improvements after rust-lang/rust#158278
This fixes a test failure on main (encountered while working on the PR above) in `tests/codegen-llvm/autodiff/autodiffv2.rs`.

Further improvements are split out into rust-lang/rust#158440, with high-level docs available in rust-lang/rustc-dev-guide#2911
Also noticed that I can (probably?) remove the llvm_enzyme cfg at this point, rust-lang/rust#158460
powerpc64le_unknown_freebsd.rs: link with -lgcc

Starting with FreeBSD 16.0, powerpc64le switches to IEEE long double. 128 bit arithmetics are implemented in LLVM's compiler_rt, which is FreeBSD's libgcc. Link with it so that building on FreeBSD 16.0 succeeds - noop for earlier releases.
 diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch

Fixes rust-lang/rust#158393

## Problem

When a closure passed to a function requiring `for<'a> FnOnce(&'a mut [u8])` has
unannotated parameters (e.g. `|buf|`), the compiler emits the confusing error:

```text
implementation of `FnOnce` is not general enough
```

without explaining how to fix it.

In many cases, simply adding an explicit type annotation to the closure
parameter (e.g. `|buf: &mut [u8]|`) resolves the lifetime ambiguity, but the
compiler does not currently provide any guidance.

## What

This PR adds a diagnostic suggestion in `placeholder_error.rs` that detects
when:

- the mismatched trait is an Fn-trait (`FnOnce`, `FnMut`, or `Fn`)
- the self type is a local closure
- one or more closure parameters do not have explicit type annotations

When these conditions are met, the compiler now emits the following help
message:

```text
help: consider adding an explicit type annotation to the closure parameter
      to resolve the lifetime ambiguity
  |
  |     let outer_closure = |buf: &mut [u8]| {
  |                             +++++++++++
```

## Testing

A UI test has been added covering the exact reproduction case from the
reported issue.
…macro, r=folkertdev

Avoid unused braces lint for macro generated arguments

Fixes rust-lang/rust#158747

This changes the `unused_braces` lint to avoid suggesting brace removal for macro arguments when those braces may affect `macro_rules!`.

But the fragment kind matters:

- `$e:expr` matches an expression. Both `1` and `{ 1 }` are expressions, so removing braces can still leave the macro matching the same kind of input.
- `$b:block` only matches a block expression written with braces. `{ 1 }` matches, but `1` does not.

So `call_expr!({ 1 })` can usually be simplified to `call_expr!(1)`, while `call_block!({ 1 })` cannot.

It seems a more concrect report need a full `macro_rules!` matcher analysis, that seems too heavy for `unused` lint.
…rcoieni

Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts


## Summary

Use our `ci-mirrors` for busybox and ubuntu rootfs artifacts instead of relying on external network sources.

Context: [#t-infra > kernel.org is borked @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/kernel.2Eorg.20is.20borked/near/608261860)

---

try-job: armhf-gnu
Avoid final override ICE for RPITIT associated types

Fixes rust-lang/rust#158824

`check_overriding_final_trait_item` was running for every associated item in an impl, including the synthetic anonymous associated type generated for RPITIT.
tests: catch up with LLVM returning f128 on the stack

In LLVM 22 the x64 MSVC ABI wasn't matched and f128 was being directly returned in %xmm0, but now it correctly returns the value via a pointer.
… r=petrochenkov

delegation: add constraints to new generic args

Constraints were not added to new generic args which caused them to be missing from HIR and this produced ICE.

Fixes rust-lang/rust#158812. Part of rust-lang/rust#118212.
r? @petrochenkov
…=nikic

tests: clean up over-constraint on LLVM feature count

Upstream dropped a feature, resulting in the invalid-attribute test failing because it was expecting "and 76 more" but now it's "and 75 more". Adjust the test to do a replacement with a placeholder on that text so the test is less brittle.
…uwer

Rollup of 19 pull requests

Successful merges:

 - rust-lang/rust#156016 (view-types: store view types in the AST)
 - rust-lang/rust#157385 (Enable Enzyme on x86_64-apple)
 - rust-lang/rust#158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS)
 - rust-lang/rust#158621 (disallow `extern "custom"` on wasm and spirv targets)
 - rust-lang/rust#158690 (delegation: support mapping of all arguments with `Self` type)
 - rust-lang/rust#158696 (Rename some `body_id` to `body_def_id`)
 - rust-lang/rust#158697 (Fixes for QNX SDP 8)
 - rust-lang/rust#158760 (Clarify that `LocalKey::try_with` may return `AccessError`)
 - rust-lang/rust#157801 (Rewrite safety requirements for `Allocator` impls)
 - rust-lang/rust#158085 (rustdoc: Fix sidebar heading order)
 - rust-lang/rust#158333 (Fix typetree generation for differentiated functions)
 - rust-lang/rust#158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc)
 - rust-lang/rust#158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch)
 - rust-lang/rust#158791 (Avoid unused braces lint for macro generated arguments)
 - rust-lang/rust#158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts)
 - rust-lang/rust#158841 (Avoid final override ICE for RPITIT associated types)
 - rust-lang/rust#158889 (tests: catch up with LLVM returning f128 on the stack)
 - rust-lang/rust#158905 (delegation: add constraints to new generic args)
 - rust-lang/rust#158922 (tests: clean up over-constraint on LLVM feature count)

Failed merges:

 - rust-lang/rust#158617 (allow mGCA const arguments to fall back to anon consts)
Predicate/clause cleanups



`Clause` is a subset of `Predicate`, more or less. (Interning makes things slightly more complicated than that.) There are numerous places where the code deals in predicates but really only clauses are possible. This PR eliminates some of them. Details in individual commits.

r? @lqd
This commit is generated by `ferrocene/tools/pull-upstream/pull.sh`.
The list of excluded files is defined in `.gitattributes`.
@ferrocene-automations ferrocene-automations Bot added automation Issue or PR created by an automation backport:never PR that should never be backported labels Jul 8, 2026
@jyn514

jyn514 commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

i think the automation is getting confused that i removed backport:never from #2447 :(

@jyn514 jyn514 closed this Jul 8, 2026
@tshepang tshepang deleted the automation/pull-upstream-HEAD/y5r2fo5j branch July 9, 2026 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automation Issue or PR created by an automation backport:never PR that should never be backported

Projects

None yet

Development

Successfully merging this pull request may close these issues.