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
  • about half the diff (900 lines) is tests and test output

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)

Further Work

• Tracking issue for release notes of #155121: Add FCW to disallow $crate in macro matcher #155784:
  • 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]

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

[rustbot]

Some changes occurred in coverage tests.

cc @Zalathar

[ZuseZ4]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: a8930df (a8930df882af409d5db502c7a23b6523079a5cd9, parent: 36ba2c7712052d731a7082d0eba5ed3d9d56c133)

[rust-timer]

Finished benchmarking commit (a8930df): 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%]	3
Regressions ❌ (secondary)	0.4%	[0.1%, 1.1%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	3

Max RSS (memory usage)

Results (primary -0.7%, secondary -2.3%)

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)	1.2%	[1.2%, 1.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-5.7%	[-5.7%, -5.7%]	1
All ❌✅ (primary)	-0.7%	[-0.7%, -0.7%]	1

Cycles

Results (secondary -4.1%)

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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.9%, -3.3%]	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%]	84
Regressions ❌ (secondary)	0.2%	[0.0%, 0.7%]	59
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.2%]	84

Bootstrap: 490.512s -> 491.535s (0.21%)
Artifact size: 394.34 MiB -> 394.41 MiB (0.02%)

[teor2345]

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)

[Zalathar]

I haven't been able to figure out what this comment is referring to, because:

• x rust-analyzer and x rust-analyzer-clippy are not valid commands
• x test rust-analyzer doesn't seem to produce those directories for me
• x test rust-analyzer-clippy isn't a valid command

View changes since the review

[teor2345]

Yeah, I think you might be right, I'm just checking locally if they're from my VS Code config or from ./x test (or some other command).

I've overridden the setting which has those directory names in my rust workspace, but they're still popping up, so maybe it's a VS Code bug/quirk.

[Zalathar]

If it turns out that you need to ignore some paths that only appear as a result of local config, remember that you can also add those paths to your local .git/info/exclude instead.