Rollup of 8 pull requests - #162975
Closed
JonathanBrouwer wants to merge 36 commits into
Closed
Rollup of 8 pull requests#162975JonathanBrouwer wants to merge 36 commits into
JonathanBrouwer wants to merge 36 commits into
Conversation
Both will be used by the amdgpu target to implement the `gpu-kernel` ABI. `address_space` specifies the address space of an indirect argument. `AmdgpuKernelArg` translates to LLVM’s byref, which is similar to on_stack/byval, however, there is no extra copy made, the pointer may not point to the stack but can point to some other address space, and the passed argument should not be modified. byval and byref are mutually exclusive, so change on_stack to an enum with the new states, Pointer (none), OnStack and AmdgpuKernelArg.
Add support to pass structs, arrays and vectors to amdgpu kernels. Scalars and vectors are taken by value, aggregates are passed by byref pointers. Structs containing a single scalar/vector are handled like a scalar. Judging from clang tests, nvptx seems to do somewhat the same, just using byval instead of byref: https://github.com/llvm/llvm-project/blob/3a8affeef4da19d39191aac316e189eca3214a8c/clang/test/CodeGenCUDA/kernel-args.cu I tested a couple of the lit test signatures on real hardware and it seems to work fine. Given the relatively simple implementation, I hope this amount of testing is enough (the C calling convention seems like a worse fit for Rust’s current ABI code, it’s still giving me headaches).
`into_owner_info` arena-allocates the created `OwnerInfo`. `ItemLowerer::with_lctx` calls `into_owner_info` and then re-arena-allocates the returned `OwnerInfo` (the reference, not the entire struct). This commit removes the latter.
As `LoweringContext::current_item_span`, because it *is* a span.
It's trivial and has a single call site.
It's just a thin wrapper around `tcx` and `resolver`. The `lower_*` methods all have a single call site and can be inlined, and `with_lctx` can just be a local fn within `lower_to_hir`. This requires increasing the visibility of some `LoweringContext::lower_*` methods that are now called outside of `item.rs`.
…value These functions didn't actually modifiy the operand or return a new or different expression. So essentially the "`fn(Box<Expr>) -> Box<Expr>` part" was an identity function. Just change it to "fn(&Expr)".
`recover_from_inc_dec` *always* returns a (fatal) `Err(_)` *except* if
the increment/decrement operator is a subexpression *and* the source of
the operand is not available in which case it emits the diagnostic and
returns `Ok(_)` (rendering it non-fatal).
This makes no sense whatsoever. For illustration purposes, listed below
are steps that would make us reach this case:
1. `rustc a.rs --crate-type=lib` where `a.rs` contains:
`#[macro_export] macro_rules! m { () => { i++ } }`.
2. Move or remove `a.rs`
3. `rustc b.rs --edition 2018 --extern a -L.` where
`b.rs` contains:
`fn main() { (a::m!()); }`.
Just make the error unconditionally fatal and add a FIXME to make it non
fatal in the future which would allow us to report name resolution errors
and what not. However, since that would be slightly more involved and
represent a behavior change (in the error path), this is out of scope for
a mere cleanup commit like this one.
There's literally no upside to use it and only downsides:
It's not more concise, only adds code and obfuscates.
Its `MultiSugg::emit{,_verbose}` didn't even *emit* the diagnostic,
they merely *decorated* it!
1. Remove unnecessary rebindings (`op_span` and `op = op.node`) 2. Remove binding `cur_op_span` as it's equal to `op.span` 3. Merge two `match`es on `op.node` into one to make the control flow more obvious and to render everything more legible. Moreover, it allows us to drop an ungly `unreachable!()`
Previously we would check if the current operator was `Binary(Lt)` and the current token was `>` to determine if we're looking at `<>`. However, since `AssocOp::from_token` also treats `<-` as `Binary(Lt)` for better error recovery, the condition would also hold for `<->` (`<-`, `>`) which is not what we want. E.g., given `1 <-> 2` we would previously emit diagnostic "invalid comparison operator `<>`". --- Also update `recover_from_spaceship_cmp_op` to do something similar -- not to fix anything but simply to eliminate param `op: Spanned<AssocOp>`.
…ertdev `core::num::f16b` Rust's 16bit Brain Float Implements the [RFC: f16b type](rust-lang/rfcs#3983). Best reviewed commit by commit, happy to split into separate PRs if that is deemed easier to review. However the line count and surface area is, in my opinion, reasonably small. Adds; - ABI plumbing for the `f16b` along with `bfloat` lang item to work with LLVM, GCC is explicitly `unimplemented!(...)` - `f16b` feature gate, page for `f16b` on libruscdoc and a `struct bf16` in `core::num` - Tests - Treat `f16b` as a scalar primitive for scalable vectors Issues; - [Tracking Issue](rust-lang#160630) - [RFC](rust-lang/rfcs#3983)
Properly implement the gpu-kernel ABI for amdgpu Add support to pass structs, arrays and vectors to amdgpu kernels. Scalars and vectors are taken by value, aggregates are passed by byref pointers. Structs containing a single scalar/vector are handled like a scalar. Judging from clang tests, nvptx seems to do somewhat the same, just using byval instead of byref: https://github.com/llvm/llvm-project/blob/e4e18dba3d77f4a3eea58bcc9ccae5a5498ede7c/clang/test/CodeGenCUDA/kernel-args.cu I tested a couple of the lit test signatures on real hardware and it seems to work fine. Given the relatively simple implementation, I hope this amount of testing is enough (the C calling convention seems like a worse fit for Rust’s current ABI code, it’s still giving me headaches). This adds two members to `PassMode::Indirect`. `address_space` specifies the address space of an on_stack/byval or by_ref pointer argument. `by_ref` translates to LLVM’s byref, which is similar to on_stack/byval, however, there is no extra copy made, the pointer may not point to the stack but can point to some other address space, and the passed argument should not be modified. Both are used by the amdgpu target to implement the `gpu-kernel` ABI. Tracking issue for the `gpu-kernel` ABI: rust-lang#135467 Tracking issue for the amdgpu target: rust-lang#135024
rustbot
added
A-attributes
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 18, 2026
Rollup of 8 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-gnu-llvm-21-3 try-job: test-x86_64-msvc-1 try-job: test-aarch64-apple-1 try-job: test-aarch64-apple-2 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 18, 2026
…uwer Rollup of 8 pull requests Successful merges: - #160859 (`core::num::f16b` Rust's 16bit Brain Float) - #162177 (Properly implement the gpu-kernel ABI for amdgpu) - #162591 (Move parse error recovery for expression operators "out of line" & refactor in the area) - #162733 (Add useful APIs to `Unique(Arc|Rc)`) - #162950 (More AST lowering cleanups) - #162964 (Update `browser-ui-test` version to `0.25.2`) - #162797 (yeet AliasConstKind::opt_def_id) - #162836 (Ping T-libs-ping instead of T-libs-fcp for backports)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for d0bc013 failed: CI. Failed job:
|
Contributor
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #160859, which is a member of this rollup, was unapproved. |
rustbot
removed
the
S-waiting-on-author
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
11 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.
Successful merges:
core::num::f16bRust's 16bit Brain Float #160859 (core::num::f16bRust's 16bit Brain Float)Unique(Arc|Rc)#162733 (Add useful APIs toUnique(Arc|Rc))browser-ui-testversion to0.25.2#162964 (Updatebrowser-ui-testversion to0.25.2)r? @ghost
Create a similar rollup