[Coverage][MCDC] Group mcdc tests and fix panic when generating mcdc code for inlined expressions.

[ZhuUx]

Changes

1. Group all mcdc tests to one directory.
2. Since mcdc instruments different mappings for boolean expressions with normal branch coverage as MCDC Coverage: instrument last boolean RHS operands from condition coverage #125766 introduces, it would be better also trace branch coverage results in mcdc tests.
3. So far rustc does not call CoverageInfoBuilderMethods::init_coverage for inlined functions. As a result, it could panic if it tries to instrument mcdc statements for inlined functions due to uninitialized cond bitmaps. We can reproduce this issue by current nightly rustc and the test with flag --release. This patch fixes it.

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
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

[rustbot]

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in coverage tests.

cc @Zalathar

[ZhuUx]

@rustbot label +A-code-coverage
cc @RenjiSann

[Zalathar]

Unfortunately, I'm pretty sure this fix is wrong.

We can't just call init_coverage in the middle of visiting an inlined coverage statement, because (even with these changes) that method is written around the assumption that it will be called exactly once, at the start of the relevant function.

For example, what happens if a function is inlined in multiple places, or is both inlined and also codegenned as a non-inlined function? It looks like only some of those places will end up with the local variables that they need.

---

For now, I think the workaround should just be to completely disable MIR inlining when MC/DC is enabled.

[Zalathar]

By the way, if you want to extract the first two patches (adjusting tests) to their own PR, they should be fine.

(I can't directly approve them myself, but I can at least tell the assigned reviewer that they're OK.)

[Zalathar]

Something like this in compiler/rustc_mir_transform/src/inline.rs should work around the problem:

impl<'tcx> MirPass<'tcx> for Inline {
    fn is_enabled(&self, sess: &rustc_session::Session) -> bool {
        // FIXME(#127234): Coverage instrumentation currently doesn't handle inlined
        // MIR correctly when Modified Condition/Decision Coverage is enabled.
        if sess.instrument_coverage_mcdc() {
            return false;
        }

[ZhuUx]

We can't just call init_coverage in the middle of visiting an inlined coverage statement, because (even with these changes) that method is written around the assumption that it will be called exactly once, at the start of the relevant function.

How about use (RootInstance, InlinedInstance) as the key to reference the local mcdc parameters?

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[ZhuUx]

Updated. Considering there might be much overhead if we created mcdc parameters for each inlined functions separately, disable inlining when mcdc is enabled seems better for now.

[davidtwco]

This looks good to me. r=me but would like to confirm that @Zalathar is happy with it, knowing coverage more than I do.

[Zalathar]

@davidtwco Yes, r+ from me also. 👍

[ZhuUx]

No change in the force push. I just rebase it to the latest master.

[nikic]

@bors r=davidtwco,Zalathar

[bors]

📌 Commit 83fa6b7 has been approved by davidtwco,Zalathar

It is now in the queue for this repository.

[bors]

⌛ Testing commit 83fa6b7 with merge 6be96e3...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco,Zalathar
Pushing 6be96e3 to master...

[rust-timer]

Finished benchmarking commit (6be96e3): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (secondary -2.1%)

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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.1%, -2.1%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 702.397s -> 703.661s (0.18%)
Artifact size: 328.67 MiB -> 328.72 MiB (0.02%)