coverage: Switch over to hybrid HIR-aware coverage spans

[Zalathar]

• Incorporates the test cleanups from coverage: Tidy tests and add some new ones #161397.

---

One of the deep flaws in coverage instrumentation at the moment is that the instrumentor doesn't have actual knowledge of source-level code structure. Instead, it resorts to guessing source spans based on scanning through MIR statements and terminators, and applying a few crude heuristics that can never give truly accurate results.

(The decision to use MIR-based spans was made during the original implementation of -Zinstrument-coverage. I was not able to find any discussion of this design decision or its consequences in the stabilization thread at #90132.)

This PR is a partial step towards a better way of doing things. During THIR-to-MIR lowering, we now inject special CoverageKind::Point marker statements that represent a specific connection between some part of the source code (in HIR form) to a specific point in MIR control-flow. Instead of trying to recover coverage spans from arbitrary MIR statements/terminators, we now only extract spans from those dedicated marker statements.

Having accurate HIR-to-MIR correlations unlocks a lot of exciting possibilities for better coverage instrumentation. This PR mostly sets the stage for potential future improvements, but does demonstrate the ability to exclude specific HIR expressions from the set of coverage spans (to make assertions less noisy), which was previously unthinkable.

---

The key to making this all work is being able to accurately inject marker statements during MIR building. There is no single point in MIR building that all THIR expressions pass through, and most THIR expression nodes do not keep track of their corresponding HirId. However, it turns out that THIR building already wraps every expression node in a thir::ExprKind::Scope node that does store the original HirId, and the number of places in MIR building that handle those scopes is relatively small. So if we simply inject an appropriate marker statement at those places, with the HirId that is already available, that takes care of marking every HIR-level expression node in the built MIR.

To avoid major regressions in coverage-span quality, we also need to inject markers in a few extra places that don't correspond to a HIR node, because they represent implied code such as the else {} of a one-sided if, or the automatic return at the end of a function body.

---

There are necessarily some changes to coverage output as a result of the new approach. I have tried to keep these minimal, but I don't think it's worth trying to chase 1:1 compatibility with the old spans, which were very much a product of several layers of implementation details and heuristics. The differences seem reasonable overall, and in some cases are a clear improvement.

[rustbot]

Some changes occurred in match lowering

cc @Nadrieril

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in match checking

cc @Nadrieril

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
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 75 candidates
• Random selection from 21 candidates

[rustbot]

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @vakaras

[Zalathar]

After some more investigation I found #145569 (comment), which suggests that for thir::Expr nodes that are not Scope, we can also recover the corresponding node from thir::Expr::temp_scope_id, since it's just the local part of the corresponding HIR node's HirId.

That might avoid the need to store a separate HirId in thir::ExprKind::If, for example.

[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.