rustc_pattern_analysis: always check that deref patterns don't match on the same place as normal constructors

[dianne]

In #140106, deref pattern validation was tied to the deref_patterns feature to temporarily avoid affecting perf. However:

• As of remove special-casing of boxes from match exhaustiveness/usefulness analysis #143414, box patterns are represented as deref patterns in rustc_pattern_analysis. Since they can be used by enabling box_patterns instead of deref_patterns, it was possible for them to skip validation, resulting in an ICE. This fixes that and adds a regression test.
• External tooling (e.g. rust-analyzer) will also need to validate matches containing deref patterns, which was not possible. This fixes that by making compute_match_usefulness validate deref patterns by default.

In order to avoid doing an extra pass for anything with patterns, the second commit makes RustcPatCtxt keep track of whether it encounters a deref pattern, so that it only does the check if so. This is purely for performance. If the perf impact of the first commit is negligible and the complexity cost introduced by the second commit is significant, it may be worth dropping the latter.

r? @Nadrieril

[rustbot]

Nadrieril is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred in exhaustiveness checking

cc @Nadrieril

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

Some changes occurred in match checking

cc @Nadrieril

[Nadrieril]

Do you want to try keeping just the first commit so we can do a perf run? Mostly out of curiosity, second commit looks good to me.

[dianne]

I'm a little curious too; is it possible to do a try build just for the first one? But if the second commit is fine, I don't see a reason not to keep the improvement! May as well not burden the build/perf infra.

[Nadrieril]

Fair, let's merge then :)

@bors r+ rollup=iffy

[bors]

📌 Commit bb64315 has been approved by Nadrieril

It is now in the queue for this repository.

[bors]

⌛ Testing commit bb64315 with merge 6b3ae3f...

[bors]

☀️ Test successful - checks-actions
Approved by: Nadrieril
Pushing 6b3ae3f to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 558d253 (parent) -> 6b3ae3f (this PR)

Test differences

Show 12 test diffs

Stage 1

• [ui] tests/ui/pattern/box-pattern-constructor-mismatch.rs: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/pattern/box-pattern-constructor-mismatch.rs: [missing] -> pass (J0)

Additionally, 10 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 6b3ae3f6e45a33c2d95fa0362c9b2593e567fd34 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-aarch64-linux: 5756.8s -> 8089.7s (40.5%)
2. dist-apple-various: 8204.4s -> 5274.3s (-35.7%)
3. dist-x86_64-apple: 6877.3s -> 8566.4s (24.6%)
4. aarch64-apple: 3952.3s -> 4813.4s (21.8%)
5. x86_64-apple-2: 4570.7s -> 3665.4s (-19.8%)
6. x86_64-apple-1: 7960.2s -> 6560.1s (-17.6%)
7. tidy: 71.5s -> 65.6s (-8.3%)
8. x86_64-gnu-llvm-19-1: 3310.1s -> 3545.8s (7.1%)
9. dist-various-1: 3955.3s -> 3697.7s (-6.5%)
10. x86_64-msvc-1: 8356.3s -> 8853.8s (6.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.