Skip to content

Rollup of 8 pull requests#154714

Closed
JonathanBrouwer wants to merge 30 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-wVuxeJK
Closed

Rollup of 8 pull requests#154714
JonathanBrouwer wants to merge 30 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-wVuxeJK

Conversation

@JonathanBrouwer
Copy link
Copy Markdown
Contributor

Successful merges:

r? @ghost

Create a similar rollup

jdonszelmann and others added 30 commits March 23, 2026 12:05
Instead of just using regular struct lowering for these types, which
results in an incorrect ABI (e.g. returning indirectly), use
`BackendRepr::ScalableVector` which will lower to the correct type and
be passed in registers.

This also enables some simplifications for generating alloca of scalable
vectors and greater re-use of `scalable_vector_parts`.

A LLVM codegen test demonstrating the changed IR this generates is
included in the next commit alongside some intrinsics that make these
tuples usable.
Clang changed to representing tuples of scalable vectors as
structs rather than as wide vectors (that is, scalable vector types
where the `N` part of the `<vscale x N x ty>` type was multiplied by
the number of vectors). rustc mirrored this in the initial implementation
of scalable vectors.

Earlier versions of our patches used the wide vector representation and
our intrinsic patches used the legacy
`llvm.aarch64.sve.tuple.{create,get,set}{2,3,4}` intrinsics for creating
these tuples/getting/setting the vectors, which were only supported
due to LLVM's `AutoUpgrade` pass converting these intrinsics into
`llvm.vector.insert`. `AutoUpgrade` only supports these legacy intrinsics
with the wide vector representation.

With the current struct representation, Clang has special handling in
codegen for generating `insertvalue`/`extractvalue` instructions for
these operations, which must be replicated by rustc's codegen for our
intrinsics to use. This patch implements new intrinsics in
`core::intrinsics::scalable` (mirroring the structure of
`core::intrinsics::simd`) which rustc lowers to the appropriate
`insertvalue`/`extractvalue` instructions.
Generate debuginfo for scalable vectors, following the structure that
Clang generates for scalable vectors.
Abstract over the existing `simd_cast` intrinsic to implement a new
`sve_cast` intrinsic - this is better than allowing scalable vectors to
be used with all of the generic `simd_*` intrinsics.
Co-authored-by: khyperia <953151+khyperia@users.noreply.github.com>
various fixes for scalable vectors

These are a handful of patches fixing bugs with the current `#[rustc_scalable_vector]` infrastructure so that we can upstream the intrinsics to stdarch:

1. Instead of just using regular struct lowering for tuples of scalable vectors, which results in an incorrect ABI (e.g. returning indirectly), we change to using `BackendRepr::ScalableVector` which will lower to the correct type and be passed in registers.
2. Clang changed from representing tuples of scalable vectors as structs rather than as wide vectors (that is, scalable vector types where the `N` part of the `<vscale x N x ty>` type was multiplied by the number of vectors). rustc mirrored this in the initial implementation of scalable vectors that didn't land.

   When our early patches used the wide vector representation, our intrinsic patches used the legacy `llvm.aarch64.sve.tuple.{create,get,set}{2,3,4}` intrinsics for creating these tuples/getting/setting the vectors, which were only supported due to LLVM's `AutoUpgrade` pass converting these intrinsics into `llvm.vector.insert`. `AutoUpgrade` only supports these legacy intrinsics with the wide vector representation.

   With the current struct representation, Clang has special handling in codegen for generating `insertvalue`/`extractvalue` instructions for these operations, which must be replicated by rustc's codegen for our intrinsics to use.

   We add a new `core::intrinsics::scalable` module (never intended to be stable, just used by the stdarch intrinsics, gated by `core_intrinsics`) and add new intrinsics which rustc lowers to the appropriate `insertvalue`/`extractvalue` instructions.
3. Add generation of debuginfo for scalable vectors, following the DWARF that Clang generates.
4. Some intrinsics need something like `simd_cast`, which will work for scalable vectors too, so this implements a new `sve_cast` intrinsic that uses the same internals as `simd_cast`. This seemed better than permitting scalable vectors to be used with the `simd_*` intrinsics more generally as I can't guarantee this would work for all of them.

This is a relatively large patch but most of it is tests, and each commit should be relatively standalone. It's a little bit easier to upstream them together to avoid needing to stack them.  It's possible that some more compiler fixes will be forthcoming but it's looking like this might be all at the moment.

Depends on rust-lang#153653

r? @workingjubilee (discussed on Zulip)
…-rustc, r=petrochenkov

Attributes containing rustc

r? @petrochenkov

I noticed that attributes *containing* the word rustc as a segment also error with a message referring to "starting with rustc". The first commit shows this going wrong by re-exporting `#[test]`, a built-in macro, from a module called rustc.

The 2nd commit addresses this by changing the diagnostic. However, given the wording I wonder if the real solution shouldn't be to allow attributes containing a `rustc` segment and only disallow them when they start. In other words, actually implement the behavior that the original diagnostic pointed out.
opaque_generic_const_args -> generic_const_args

This is part of a larger rework/plan of how to move forward with GCA. Please comment here, or message/ping me or @BoxyUwU if you have questions about the future of oGCA/GCA!

For ease of review, the first commit is renaming, and the second commit is removing the opaque parts.

fyi @camelid

r? @BoxyUwU
…smute-tests, r=Kivooeo,Teapot4195

Migrate transmute tests

I have made the following changes in this PR:

- `tests/ui/issues/issue-23477.rs` ➝ `tests/ui/transmute/transmute-slice-to-dst.rs`
- `tests/ui/issues/issue-28625.{rs,stderr}` ➝ `tests/ui/transmute/transmute-associated-type-to-slice.{rs,stderr}`

The reason I changed the trait name from `trait Bar` to `trait MyTrait` and `type Bar` to `type MyType` is that the same name (i.e., `Bar`) for the trait and associated type was making it harder to follow the test. It was confusing for me, at least.

r? Kivooeo
…boxyuwu

Rename `probe_ty_var` to `try_resolve_ty_var`

r? @lcnr
…alias, r=lcnr

Revert `Ty` type alias in `rustc_type_ir`

Reverting (rust-lang#154270) the creation and use of `Ty` type alias in `rustc_type_ir` that was causing problems with Rust Analyser, see [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/.23154270.20.28Ty.20alias.29.20triggers.20many.20bogus.20RA.20errors/with/583209227) for more

r? @lcnr
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Apr 2, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Apr 2, 2026
@JonathanBrouwer
Copy link
Copy Markdown
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 2, 2026

📌 Commit bac466e has been approved by JonathanBrouwer

It is now in the queue for this repository.

@JonathanBrouwer
Copy link
Copy Markdown
Contributor Author

Trying commonly failed jobs
@bors try jobs=test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple,x86_64-mingw-1

@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 Apr 2, 2026
@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Apr 2, 2026
Rollup of 8 pull requests


try-job: test-various
try-job: x86_64-gnu-aux
try-job: x86_64-gnu-llvm-21-3
try-job: x86_64-msvc-1
try-job: aarch64-apple
try-job: x86_64-mingw-1
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 2, 2026

☀️ Try build successful (CI)
Build commit: 9d69d99 (9d69d99e642846762f908c09785c4f3fbc34bcb2, parent: e6b64a2f4c696b840f8a384ec28690eed6a5d267)

@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 Apr 2, 2026
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 2, 2026

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-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. 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.

9 participants