Add arg splat experiment initial tuple impl

[teor2345]

View all comments

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

• Tracking Issue for argument splatting lang experiment #153629
• https://rust-lang.github.io/rust-project-goals/2026/overloading-for-ffi.html
• https://rust-lang.github.io/rust-project-goals/2025h2/interop-problem-map.html

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 and tupling
• feature gate and UI tests for item type filtering, non-splattable arguments, splattable tuples, generics, and the "overloading at home" example

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

Unrelated Changes

• Fix a comment typo in a UI test
• Add rust-analyzer target dirs to .gitignore (created by some tests)

TODOs

• Preserve as much of Refactor FnDecl and FnSig non-type fields into a new wrapper type #155223's perf wins as possible

Out of Scope for this PR

• Change codegen to de-tuple caller and callee
• Improve perf of splatting (by decreasing memory usage) by storing only a splatted flag, and looking up the argument index from the span attributes every time

[rustbot]

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]

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]

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

[Zalathar]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 09bdcac (09bdcacc122783c42bf339f270461b2a461748b7, parent: 1bfcb284f7a2199ad322daa463e29e708d5bc635)

[rust-timer]

Finished benchmarking commit (09bdcac): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	2
Regressions ❌ (secondary)	0.4%	[0.1%, 1.1%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	1
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	2

Max RSS (memory usage)

Results (secondary 4.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.8%	[4.2%, 5.1%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.6%	[3.6%, 3.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.7%	[-6.0%, -3.4%]	2
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.1%, secondary 0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.2%]	77
Regressions ❌ (secondary)	0.2%	[0.0%, 0.7%]	57
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.2%]	77

Bootstrap: 491.717s -> 491.643s (-0.02%)
Artifact size: 394.44 MiB -> 394.50 MiB (0.02%)

[teor2345]

Edit: the regressions are in nalgebra, image, the CTFE stress tests, and wg-grammar. They reverse 30-60% of the gain from #155223, but only for those specific benchmarks. The only benchmark that's worse overall is the secondary CTFE stress test.

As expected, adding a 2 byte splatted argument index to FnDecl and FnSig partly reverses some of the performance gains from removing 2 or 3 bytes from them here: #155223 (comment)

It might be possible to keep the performance gains by storing just one bit for "an argument is splatted", and looking up the actual argument only when needed.

Are there side-tables that can be used for FnDecl and FnSig?

There's also a more cursed version, which stores one byte for "a low index argument is splatted", and has a marker value for "look up the splatted argument index". (We'd need to test splatted functions with 254-257 arguments, so I'd prefer not to do that unless absolutely needed.)

[rustbot]

Some changes occurred in coverage tests.

cc @Zalathar