exhaustiveness: Rework constructor splitting

[Nadrieril]

SplitWildcard was pretty opaque. I replaced it with a more legible abstraction: ConstructorSet represents the set of constructors for patterns of a given type. This clarifies responsibilities: ConstructorSet handles one clear task, and diagnostic-related shenanigans can be done separately.

I'm quite excited, I had has this in mind for years but could never quite introduce it. This opens up possibilities, including type-specific optimisations (like using a FxHashSet to collect enum variants, which had been hackily attempted some years ago), my one-pass rewrite (#116042), and future librarification.

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[Nadrieril]

@bors try @rust-timer queue

[bors]

⌛ Trying commit fda0301 with merge 48efd89...

[bors]

☀️ Try build successful - checks-actions
Build commit: 48efd89 (48efd890e2a255f77efda76cdd4a66b3ca2061fa)

[rust-timer]

Finished benchmarking commit (48efd89): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-3.4%	[-3.8%, -3.1%]	6
All ❌✅ (primary)	-0.4%	[-0.4%, -0.4%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.6%	[0.4%, 4.4%]	8
Improvements ✅ (primary)	-1.0%	[-1.0%, -1.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.0%	[-1.0%, -1.0%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 620.955s -> 620.956s (0.00%)
Artifact size: 271.99 MiB -> 272.07 MiB (0.03%)

[petrochenkov]

r? compiler

[Nadrieril]

@cjgillot I took your comments from #116042 into account here. The only other differences between here and there are a few word changes, and I no longer allocate seen into a vector in ConstructorSet::split.

[cjgillot]

Why can't we reuse Single?

[Nadrieril]

Well you got me thinking and it turns out that they don't completely behave like Single after all. We're allowed to match with slices of arbitrary length, it's just that lengths !=0 will be unreachable.

fn foo(nevers: &[!]) {
    match nevers {
        &[]  => (),
        &[_]  => (),
        &[_, _, _, ..]  => (),
    };
}

I had completely missed that. It ended up ok because erring on the side of having more constructors in present doesn't affect correctness but still. Fixed it now. You've got a good instinct :D

[cjgillot]

@bors r+

[bors]

📌 Commit c1b29b3 has been approved by cjgillot

It is now in the queue for this repository.

[bors]

⌛ Testing commit c1b29b3 with merge e20cb77...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing e20cb77 to master...

[rust-timer]

Finished benchmarking commit (e20cb77): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.3%]	4
Regressions ❌ (secondary)	3.9%	[0.5%, 5.8%]	9
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.4%, 0.3%]	5

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.9%	[1.0%, 5.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.0%	[-1.1%, -1.0%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.7%, 0.7%]	1
Regressions ❌ (secondary)	1.2%	[1.2%, 1.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.7%, 0.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 626.794s -> 628.455s (0.26%)
Artifact size: 271.27 MiB -> 271.30 MiB (0.01%)

[Nadrieril]

I'm baffled: the previous perf run showed a perf improvement on match-stress, and the in-between commits didn't change anything remotely related to enums. I can only guess that c1b29b3 (#116391) affected codegen somehow. Maybe instrumentation prevented inlining something?

[pnkfelix]

Visiting for weekly performance triage

• the primary regressions were to cranelift-codegen-0.82.1 and cargo-0.60.0 in various incremental settings (mostly check builds)
• the large (>5%) secondary regressions are all to match-stress.
• the above cases were regressions for instruction-counts, but the cycle-counts didn't get marked as regressed in any of the same cases.
• in all cases, the performance loss from these regressions was subsequently recovered (or masked) by PR 116505 "Automatically enable cross-crate inlining for small functions".
  (I don't know if that's actually related or just an awesome change that bought so much performance that it masked this problem).
• Since the match-stress one was relatively large, I looked at the self-profile results in the details which indicates a change in the delta(time) for match-stress might be due to new overheads in check_match and mir_borrowck.
• But this is strange; I cannot tell how this PR could have affected codegen, which would be the only way I could imagine those functions being impacted.
• Not marking as triaged for now; this mystery might be worth looking into a bit more. (But then again, the only significant regression was to a secondary stress test, so maybe its not worth spending time on.)

[Nadrieril]

For context, match-stress has always been extra-sensitive to anything I touch in exhaustiveness. Any layout change or inlining decision can affect it by a few percent