Skip to content

Rollup of 11 pull requests - #162632

Closed
Zalathar wants to merge 40 commits into
rust-lang:mainfrom
Zalathar:rollup-x12Cf0M
Closed

Rollup of 11 pull requests#162632
Zalathar wants to merge 40 commits into
rust-lang:mainfrom
Zalathar:rollup-x12Cf0M

Conversation

@Zalathar

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

mejrs and others added 30 commits September 1, 2026 01:09
Co-authored-by: Jubilee <workingjubilee@gmail.com>
* Refactor `HygieneEncodeContext`
* Review: remove comment outdated part
* Review: return `raw_encode_syntax_context` as a free function
* Review: small cleanups
* Review: add comment about expansions data `Option`
* Review: don't set explicit capacity
* Review: return `queued` -> `latest`
* Remove not needed changes
* Fix `Rc` cloning
* Return comment
As a Tier 1 (without host tools) target.

- Fix an outdated claim that all T1 targets have host tools, since
  `i686-pc-windows-msvc` no longer does.
- Remove a duplicate Tier 1 section.
- Put `i686-pc-windows-msvc` under its own Tier 1 without host tools
  section.
We no longer ship host tools for this target.
…nkov

Refactor `HygieneEncodeContext`

Some refactorings around `HygieneEncodeContext` with minor perf improvements, the most notable thing is that `Lock`s were removed.

First part for rust-lang#161450.

r? @petrochenkov
…d-braces-temp-scope-lite, r=oli-obk

Skip linting unused braces for FunctionArg and MethodArg context for 2024 later

Fixes rust-lang#154247

`unused_braces` is a AST level lint, but in Rust 2024 braces around function and method arguments can affect temporary drop scope.

I tried to find a more complete fix for it, but seems all too heavy, which involve AST visitor or need `hir` related stuff.

Instead of teaching this lint to reason about semantics, so it's better to stop linting those argument-position braces in 2024 later edition.
…ingjubilee

Refactor the way cg_ssa handles indirect returns (returns via `sret`) — Take 2

This continues the work that @FractalFir done in rust-lang#144976.

**I managed to make this work, so this confirms the original approach works and is ready to merge.**

r? workingjubilee

(assigning the same reviewer as the original PR)

# The problem

The current way `cg_ssa` handles `PassMode::Indirect` is fundamentally incompatible with the requirements of the GCC backend. This is currently worked around in a very brittle way, that breaks on ARM.

In order to function correctly, `cg_gcc` requires the `sret`(indirect return) pointer to be treated in a special way.

# The solution

This PR separates the `sret` pointer from all the other arguments, allowing each backend to decide how it wants to handle that pointer. This will allow GCC to do it's own thing, while changing nothing on the LLVM side. Currently, the PR just makes both backends preappend the sret arg, mimicking the previous behaviour.

The PR is based on this [zulip suggestion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Bootstrap.20of.20rustc.20with.20rustc_codegen_gcc/near/526487725).

# Assumptions I made.

The PR makes certain assumptions about the ABI handling.

1. No LLVM intrinsic returns via sret. [According to my sources](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Can.20LLVM.20intrinsics.20return.20via.20PassMode.3A.3AIndirect.3F), this is always true.
2. Tail calls don't currently return via `sret`. From [asking about](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Can.20tail.20calls.20return.20indirectly.28via.20a.20pointer.29.3F/near/532984507), it seems like the tail call handling does not currently support indirect returns. So, I did not add support for that.
3. TLS shims don't perform indirect returns, and asserts and drops also don't perform indirect returns(since they return nothing) - those assumptions seemed reasonable.
4. Inline assembly calls don't use indirect returns. I *assumed* functions like `inline_asm_call` will not need the `sret` handling code. I am not 100% sure about this, tough.
Implement arbitrary casts in custom mir

[See zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/extending.20custom.20MIR/with/613727602)

Implement custom casts using an enum in `intrinsics::mir` that closely matches the `CastKind` enum in the compiler.

We have 5 different ways to cast in custom MIR, 3 with functions (which hard code a cast kind), 1 implicit coerce (which only does subtyping i think), 1 with `as` (which does a few more). They are all different and the error messages don't tell you what to do. Some are (i think) not possible at all.

This came up [while testing miri](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Valdity.20checks.20for.20references/near/613662285). We currently have to guess the casting syntax until we find the one that generates the MIR we want. This PR changes that by adding a custom mir operation that allows picking an arbitrary cast.

r? RalfJung
…thanBrouwer

Use attribute parser for `#[non_exhaustive]` attribute check

Updates rust-lang#153101

r? @JonathanBrouwer
…n, r=adwinwhite

deeper `rustc_builtin_macros` cleanups

As a followup to rust-lang#161464, this contains a few more surface cleanups and begins simplifying the mess that `SubstructureFields` currently is by removing the `StaticFields` type in favor of just using the `VariantData` directly.
small refactor of doc attribute arguments warnings
split `macroless_generic_const_args` in two

Two's a crowd! But One's a lonely.

Having `macroless_generic_const_args` apply to const items was quite annoying for users especially as we moved away from `type const` to just regular const items. We would quite commonly be "guessing wrong" with no easy way for users to opt out of `const ASSOC: usize = ...` being represented directly instead of an opaque body

I just swapped any failing tests over to using macroless_const_item_generic_const_args, didnt look through the whole set :>

We should probably bikeshed the feature name rn because it's currently inconsistent with what we wanted to rename all of the other gca features too :> Maybe this should be `gca_macroless_const_items`

cc rust-lang#162540

r? khyperia
The fuchsia team maintains `riscv64gc-unknown-fuchsia`

The fuchsia team maintains `riscv64gc-unknown-fuchsia` target (cc rust-lang#113739).
…r=khyperia

Fix `i686-pc-windows-msvc` platform support docs and target spec metadata

## Summary

Follow-up fixes to rust-lang#162288.

- Fix an outdated claim that all T1 targets have host tools, since `i686-pc-windows-msvc` no longer does.
- Remove a duplicate Tier 1 section.
- Put `i686-pc-windows-msvc` under its own Tier 1 without host tools

## Context

* `i686-pc-windows-msvc` Tier 1 (with host tools) => Tier 1 (without host tools) RFC: rust-lang/rfcs#3999
* cc rust-lang#158378
…ion-closure-capture, r=beetrees

regression test for opaque field projection in closure capture

Closes rust-lang#156837
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Sep 11, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) F-autodiff `#![feature(autodiff)]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. labels Sep 11, 2026
@Zalathar

Copy link
Copy Markdown
Member Author

Rollup of everything.

@bors r+ rollup=never p=5

@rust-bors

rust-bors Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 4b63200 has been approved by Zalathar

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 Sep 11, 2026
@Zalathar

Copy link
Copy Markdown
Member Author

Closing as identical to #162631.

@Zalathar Zalathar closed this Sep 11, 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 Sep 11, 2026
@rust-bors

rust-bors Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

@Zalathar
Zalathar deleted the rollup-x12Cf0M branch September 11, 2026 10:48
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. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) F-autodiff `#![feature(autodiff)]` 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-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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.