Arg splat experiment - HIR FnSig 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

I've split it from #153697 to make reviewing easier, see that PR for more details.

The PR is the HIR-level FnSig implementation of the feature (next PR will be typecheck):

• Add splat to HIR FnSig
  • which changes legacy mangling scheme function hashes due to the extra bytes
• splat mismatch support, including function pretty-printing
• various FIXME comments

Once this PR merges, I'll rebase #153697.

There aren't any extra tests in this PR, because it doesn't have any externally visible functionality. The visible functionality and tests are in the rest of #153697.

[rustbot]

HIR ty lowering was modified

cc @fmease

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

miri is developed in its own repository. If possible, consider making this change to rust-lang/miri instead.

cc @rust-lang/miri

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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, types
• compiler, types expanded to 73 candidates
• Random selection from 19 candidates

[teor2345]

These attributes don't seem to be necessary, but should they be kept anyway?

Suggested change

	_marker: PhantomData<fn() -> I>,
	#[type_visitable(ignore)]
	#[type_foldable(identity)]
	_marker: PhantomData<fn() -> I>,

View changes since the review

[rustbot]

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.

[panstromek]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: d8eafa9 (d8eafa9dcccd482a75209dc4bc1bd346e954d333, parent: 01dfd79246f1b2d5f146616deff08223a840a9ae)

[rust-timer]

Finished benchmarking commit (d8eafa9): 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.1%, 0.9%]	14
Regressions ❌ (secondary)	0.3%	[0.1%, 0.5%]	16
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.1%, 0.9%]	14

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (secondary -12.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)	4.6%	[4.6%, 4.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-28.8%	[-28.8%, -28.8%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.1%, secondary 0.1%)

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.1%	[0.0%, 0.7%]	65
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.2%]	84

Bootstrap: 519.231s -> 521.837s (0.50%)
Artifact size: 401.41 MiB -> 400.94 MiB (-0.12%)

[teor2345]

Ok, that's a significant regression we should fix before merging if possible. Waiting on perf on #157954 and #157955 to see if an attribute query (or side-table) or inlining is the best approach here.

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[teor2345]

Inlining doesn't work, so we'll need to do the equivalent of #157954 for FnSig: 1 bit in the FnSig to mark any splatting, then look up the actual splatted argument in the attributes or a side-table.

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/macro.find_attr.html is how you query attrs for an item? I would guess find_attr!(tcx, def_id, AttributeKind::Splat => ())

This might require putting the argument attribute in the cross-crate def_id table, like we do for HIR here: https://github.com/rust-lang/rust/pull/157954/changes#diff-ad0c15bbde97a607d4758ec7eaf88248be5d6b8ae084dfc84127f81e3f7a9bb4R1880

This should improve performance by making FnSig smaller, but it won't be as good a #157954, because there are no spare bits in FnSig currently.

Edit: another alternative is just using one byte, and rejecting splatting past the 255th argument.