Add arg splat experiment initial tuple impl by teor2345 · Pull Request #153697 · rust-lang/rust

teor2345 · 2026-03-11T08:23:19Z

View all comments

This PR is part of the argument splatting lang experiment, and FFI overloading / C++ interop project goals:

Example code using existing unstable features:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=f42a3754a63a3d9365670e57257053d5

Discussion of implementation strategy:

#t-lang > On overloading @ 💬

The PR is the initial implementation of the feature:

splat incomplete feature gate
#[splat] attribute on function arguments
#[splat] function parameter check at THIR level
splatted MIR lowering (as tupled arguments)
feature gate and UI tests for item type filtering, non-splattable arguments, splattable tuples, generics, and the "overloading at home" example
- about half the diff (1100 lines) is tests and test output

Once this PR merges, we can add further functionality, then test it out in interop tools.

Further Work

perf: Use 1 bit to track splatting in FnDecl #155852:
- Preserve Refactor FnDecl and FnSig non-type fields into a new wrapper type #155223's perf wins with a minor refactor (and some const / inline fns)

Out of Scope for this PR

Change codegen to de-tuple caller and callee
Better diagnostics
Full support for splatted function pointer arguments

rustbot · 2026-03-11T08:23:24Z

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 69 candidates
Random selection from 16 candidates

JohnTitor · 2026-03-11T10:19:07Z

It should be better for someone on https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/On.20overloading/with/573924937 to review this, @oli-obk could you take over?

oli-obk · 2026-03-12T06:45:05Z

Let's wait for the ongoing discussion on Zulip to figure out whether we need to have a proc macro, an AST manipulating attribute (like define_opaque), or just a normal attribute

teor2345 · 2026-04-27T06:07:37Z

The perf issues above are resolved by a minor refactor, but I'd like to merge them as separate PRs/commits, just in case we need to go back to the original code for testing (or further refactors).

See the perf analysis here, overall this PR plus the refactor in #155852 results in an 0.24% primary benchmark improvement, with no primary regressions:
#155852 (comment)

oli-obk · 2026-04-28T07:40:37Z

+
+        // Multiple splatted arguments are invalid: we can't know which arguments go in each splat.
+        if splatted_arg_indexes.len() > 1 {
+            self.dcx().emit_err(errors::DuplicateSplattedArgs { spans: splatted_spans.clone() });


I'm somewhat worried that due to these errors being non-blocking for the rest of the compiler, that it's possible to cause weird ICEs, but that's nothing new wrt most of the ast validation checks.

View changes since the review

I did my best to provide sensible defaults/substitutions on error.

Specifically, c_variadic gets priority, then the first splatted argument. Every other splat generates an error, then gets ignored in later stages.

oli-obk · 2026-04-28T07:49:55Z

+    /// Which function argument is splatted into multiple arguments in callers, if any?
+    /// Splatting functions with `u16::MAX` arguments is not supported, see `FnSigKind` for
+    /// details.
+    splatted: u16,


far future possibility: make newtype_index allow for types other than u32 to be used for the storage. Then we could just encode a new ArgIdx type that inherently forbids u16::MAX (and maybe a few others at the upper limit to allow for more niche opts)

View changes since the review

also 😭 why do we allow more than 250 arguments on functions

It might make the compiler faster to limit it to 256 arguments, I wonder if that would break any code.

At least we test for u16::MAX arguments. It used to panic, see #88577.

oli-obk · 2026-04-28T07:52:31Z

-    /// Create a new FnDeclKind with no implicit self, no lifetime elision, and no C-style variadic argument.
+    /// Marker index for "no splatted argument".
+    /// Must have the same value as `FnSigKind::NO_SPLATTED_ARG_INDEX` and `rustc_ast::FnDecl::NO_SPLATTED_ARG_INDEX`.
+    const NO_SPLATTED_ARG_INDEX: u16 = u16::MAX;


can these all be linked somehow by depending on them in the argument? Or are there two of them who don't have the others' crate in their dependency list?

View changes since the review

I tried, but there's no common dependency crate to put the constant in.

Some of these instances will disappear in #155852 as part of a perf refactor (if it still gives good perf after recent nearby changes).

oli-obk · 2026-04-28T09:14:21Z

+                    let ocx_error =
+                        ocx.eq(&origin, self.param_env, calee_tuple_type, new_tupled_type);
+                    if let Err(ocx_error) = ocx_error {
+                        struct_span_code_err!(


is this error reachable? if so, please add a test specifically for it

View changes since the review

I'm not sure if it's reachable, and I don't know how to create a test for this. It seems like other errors happen first, but there might be a way to trigger it. I left a FIXME in the code.

I made a bunch of related fixes and tests while trying to test this:

fixed some invalid method splatted self argument handling which resulted in an ICE (there's a test for it now)

cleaned up some unnecessary diagnostic function arguments

some error messages were outdated (splat is supported on any argument) so I updated them

use the argument span in some error messages, rather than using the argument number

add tests for generics that might be tuples, and for unresolvable/ambiguous types

RalfJung · 2026-04-28T11:47:25Z

        };

        // Split the rust-call tupled arguments off.
+        // FIXME(splat): un-tuple splatted arguments in codegen, for performance


Why "for performance"? If this follows the RustCall approach, the ABI requires untupling for correctness. I am confused by this comment.

View changes since the review

Oh I see, I think I got confused by "splatted MIR lowering and tupling". This doesn't actually do anything on the ABI level yet, it passes things as structs.

Refactor FnDecl and FnSig non-type fields into a new wrapper type #### Why this Refactor? This PR is part of an initial cleanup for the [arg splat experiment](rust-lang/rust#153629), but it's a useful refactor by itself. It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR: rust-lang/rust#153697 (comment) It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults. #### Relationship to `splat` Experiment I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment. Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added. This PR packs these types: - ExternAbi: enum + `unwind` variants (38) -> 6 bits - ImplicitSelfKind: enum variants (5) -> 3 bits - lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit #### Minor Changes Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.

fixup! Add splat builtin attribute & feature gate

fixup! Add AST validation for #[splat]

fixup! Add HIR FnDecl for #[splat]

fixup! Impl HIR typeck for #[splat]

fixup! Impl TypeInfo for splat

rustbot · 2026-05-05T10:41:23Z

The reflection data structures are tied exactly to the implementation
in the compiler. Make sure to also adjust rustc_const_eval/src/const_eval/type_info.rs

cc @oli-obk

teor2345

This should be ready for another review.

I've rebased this on the latest main, trying to minimise the number of rebase changes to earlier commits. The rebase was tricky, so there are some fixes which should be squashed into earlier commits, and some code might not quite be in the nicest/clearest commit.

The last 5 commits are revisions from the latest reviews, the detailed commit message says which commit they revise.

View changes since this review

teor2345 · 2026-05-04T03:08:45Z

+    /// Which function argument is splatted into multiple arguments in callers, if any?
+    /// Splatting functions with `u16::MAX` arguments is not supported, see `FnSigKind` for
+    /// details.
+    splatted: u16,


It might make the compiler faster to limit it to 256 arguments, I wonder if that would break any code.

At least we test for u16::MAX arguments. It used to panic, see #88577.

teor2345 · 2026-05-04T03:22:00Z

-    /// Create a new FnDeclKind with no implicit self, no lifetime elision, and no C-style variadic argument.
+    /// Marker index for "no splatted argument".
+    /// Must have the same value as `FnSigKind::NO_SPLATTED_ARG_INDEX` and `rustc_ast::FnDecl::NO_SPLATTED_ARG_INDEX`.
+    const NO_SPLATTED_ARG_INDEX: u16 = u16::MAX;


I tried, but there's no common dependency crate to put the constant in.

Some of these instances will disappear in #155852 as part of a perf refactor (if it still gives good perf after recent nearby changes).

teor2345 · 2026-05-04T03:24:30Z

+        splatted: Option<u16>,
+        args_len: usize,
+    ) -> Result<Self, SplattedArgIndexError> {
+        if let Some(splatted_arg_index) = splatted {


Yeah, I wasn't sure about this either.

I felt like having the option was clearer in callers, and tried to keep the sentinel value as an internal implementation detail which never appears outside the low-level bit-packing code. That way, providing u16::MAX as the splatted argument is easy to error on.

But I don't mind dropping the option, it's unlikely this case will be encountered in practice.
What do you think?

teor2345 · 2026-05-05T03:20:01Z

+                    let ocx_error =
+                        ocx.eq(&origin, self.param_env, calee_tuple_type, new_tupled_type);
+                    if let Err(ocx_error) = ocx_error {
+                        struct_span_code_err!(


I'm not sure if it's reachable, and I don't know how to create a test for this. It seems like other errors happen first, but there might be a way to trigger it. I left a FIXME in the code.

I made a bunch of related fixes and tests while trying to test this:

fixed some invalid method splatted self argument handling which resulted in an ICE (there's a test for it now)

cleaned up some unnecessary diagnostic function arguments

some error messages were outdated (splat is supported on any argument) so I updated them

use the argument span in some error messages, rather than using the argument number

add tests for generics that might be tuples, and for unresolvable/ambiguous types

teor2345 · 2026-05-05T10:39:05Z

+
+        // Multiple splatted arguments are invalid: we can't know which arguments go in each splat.
+        if splatted_arg_indexes.len() > 1 {
+            self.dcx().emit_err(errors::DuplicateSplattedArgs { spans: splatted_spans.clone() });


I did my best to provide sensible defaults/substitutions on error.

Specifically, c_variadic gets priority, then the first splatted argument. Every other splat generates an error, then gets ignored in later stages.

rustbot · 2026-05-05T10:41:25Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot assigned JohnTitor Mar 11, 2026

rustbot added 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. labels Mar 11, 2026

teor2345 mentioned this pull request Mar 11, 2026

Tracking Issue for argument splatting lang experiment #153629

Open

19 tasks

This comment has been minimized.

Sign in to view

oli-obk reviewed Mar 11, 2026

View reviewed changes

Comment thread compiler/rustc_builtin_macros/src/splat.rs Outdated

oli-obk assigned oli-obk and unassigned JohnTitor Mar 11, 2026

oli-obk added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Mar 12, 2026

teor2345 marked this pull request as draft March 13, 2026 06:49

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Mar 13, 2026

teor2345 force-pushed the fn-arg-splat-experiment branch from 89102bf to c784a57 Compare March 16, 2026 07:35

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Mar 16, 2026

programmerjake reviewed Mar 16, 2026

View reviewed changes

Comment thread compiler/rustc_attr_parsing/src/attributes/codegen_attrs.rs Outdated

programmerjake reviewed Mar 16, 2026

View reviewed changes

Comment thread compiler/rustc_hir/src/target.rs

programmerjake reviewed Mar 16, 2026

View reviewed changes

Comment thread tests/ui/splat/splat-non-function.rs Outdated

teor2345 force-pushed the fn-arg-splat-experiment branch from c784a57 to 2d9e563 Compare March 20, 2026 01:37

rustbot added 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) labels Mar 20, 2026

This comment was marked as outdated.

Sign in to view

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

teor2345 mentioned this pull request Mar 20, 2026

Fix typos and markdown errors #154121

Merged

This comment has been minimized.

Sign in to view

rustbot added the T-clippy Relevant to the Clippy team. label Mar 20, 2026

teor2345 force-pushed the fn-arg-splat-experiment branch from d83e6d9 to d4229d6 Compare April 26, 2026 22:36

This comment has been minimized.

Sign in to view

teor2345 force-pushed the fn-arg-splat-experiment branch from d4229d6 to 482f842 Compare April 26, 2026 23:44

teor2345 mentioned this pull request Apr 27, 2026

perf: Use 1 bit to track splatting in FnDecl #155852

Draft

3 tasks

Zalathar reviewed Apr 27, 2026

View reviewed changes

Comment thread .gitignore Outdated

teor2345 force-pushed the fn-arg-splat-experiment branch from 482f842 to 84cab65 Compare April 28, 2026 01:19

This comment was marked as outdated.

Sign in to view

oli-obk requested changes Apr 28, 2026

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Apr 28, 2026

This comment has been minimized.

Sign in to view

RalfJung reviewed Apr 28, 2026

View reviewed changes

teor2345 mentioned this pull request Apr 29, 2026

Add a missing GenericTypeVisitable, and avoid having interner traits for FnSigKind and Abi #155562

Merged

teor2345 added 11 commits May 5, 2026 18:46

Add splat builtin attribute & feature gate

a57f0ae

Add AST validation for #[splat]

12cbb30

Add HIR FnDecl for #[splat]

6af64c8

Impl HIR typeck for #[splat]

ed63b76

Impl MIR lowering for #[splat]

bb6293a

Impl TypeInfo for splat

c0ee4d3

Stop allowing #[splat] on macro calls, for now

be7ac75

fixup! Add splat builtin attribute & feature gate

Fix a #[splat] AST validation method comment

a49e71e

fixup! Add AST validation for #[splat]

Make the param_info return type into a struct, and rename the function

ab9d855

fixup! Add HIR FnDecl for #[splat]

Extract splatted typeck into a fn and cleanup error handling

c42e116

fixup! Impl HIR typeck for #[splat]

Add splat to libcore's TypeInfo

fdd4be9

fixup! Impl TypeInfo for splat

teor2345 force-pushed the fn-arg-splat-experiment branch from 84cab65 to fdd4be9 Compare May 5, 2026 10:41

teor2345 commented May 5, 2026

View reviewed changes

Uh oh!

Conversation

teor2345 commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Further Work

Out of Scope for this PR

Uh oh!

rustbot commented Mar 11, 2026

Uh oh!

This comment has been minimized.

Uh oh!

JohnTitor commented Mar 11, 2026

Uh oh!

oli-obk commented Mar 12, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as outdated.

This comment has been minimized.

This comment was marked as resolved.

Uh oh!

This comment has been minimized.

This comment has been minimized.

teor2345 commented Apr 27, 2026

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

oli-obk Apr 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

oli-obk Apr 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oli-obk Apr 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

oli-obk Apr 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment has been minimized.

RalfJung Apr 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented May 5, 2026

Uh oh!

teor2345 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

teor2345 commented Mar 11, 2026 •

edited

Loading

oli-obk Apr 28, 2026 •

edited by rustbot

Loading

oli-obk Apr 28, 2026 •

edited by rustbot

Loading

oli-obk Apr 28, 2026 •

edited by rustbot

Loading

oli-obk Apr 28, 2026 •

edited by rustbot

Loading

RalfJung Apr 28, 2026 •

edited by rustbot

Loading

teor2345 left a comment •

edited by rustbot

Loading