Implement and Maintain MC/DC Coverage Support

[tomassedovic]

Metadata
Point of contact	@RenjiSann
Team(s)	compiler, infra
Goal document	2026/mcdc-coverage-support

Summary

Re-implement DC (Decision Coverage) and [MC/DC (Modified Condition/Decision Coverage)][mcdc-wikipedia] instrumentation in rustc with a commitment to ongoing maintenance from AdaCore.

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@RenjiSann
Team(s)	compiler, infra
Goal document	2026/mcdc-coverage-support

Summary

Re-implement DC (Decision Coverage) and [MC/DC (Modified Condition/Decision Coverage)][mcdc-wikipedia] instrumentation in rustc with a commitment to ongoing maintenance from AdaCore.

Tasks and status

[tomassedovic]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[RenjiSann]

Mid-May update

In the last few weeks, we've investigated what it means to apply MC/DC to Pattern-Matching, which turned out to be more difficult to resolve than anticipated.

Naive pattern to boolean expression translation

Initially, we thought of naively translating patterns in boolean expression, on which we could then compute MC/DC.

Example:

enum X {A, B, C}

let x = Some(X::A);

match x {
    Some(X::A) | None => todo!(),
    _ => todo!(),
}

Here, the first pattern could be interpreted as the following boolean decision:
discriminant(x) == Some && discriminant(x.0) == X::A || discriminant(x) == None

The issue with this approach is that the OR-pattern creates coupled conditions: both checks to the discriminant of x can only ever be the opposite of the other. This makes the translated decision un-coverable as per MC/DC definition.

Starting from here, an idea could be to find a equivalent boolean expression that would be coverable. In this specific case, there could be discriminant(x) == None || discriminant(x.0) == X::A, but this change would not work anymore if the Option type had a third variant.

Input from certification experts

We discussed with Adacore's in-house certification expert team. They usually works with the certification assessors, so their input is very interesting to understand what we need to be careful of to make software that will indeed be certified.

Here are their advices:

• Pattern-matching is a "data-flow" paradigm, as opposed to the "control-flow" paradigm of boolean expressions, which is why applying MC/DC to it feels weird.
• Whatever criterion we come up with, it must be relatively easy to understand, so assessors can check it by hand without being rust experts.
• They redirected us to a paper explaining how the SCADE software (a data-flow, diagram-based language made for building safety-critical applications) implemented coverage. We are investigating it at the moment.

Possible limitations

Since the principal obstacle to making naive boolean expressions coverable, we could for example decide to forbid the OR-patterns in complex patterns. That is, preventing the use of OR-patterns, unless it's the root pattern and each of their children is a leaf pattern.

Additionnally, the instrumentation will eventually rely on variable range analysis to detect patterns rendered "irrefutable by context". Since if-guards mess up with VRA, it would be safer to forbid their use in safety-critical context.

At first glance, these sound like reasonable limitations, compared to what we are used to in the safety-critical industry. Nonetheless, we will conduct a study to understand how pervasive these patterns are, namely in the lib core and lib std. Hopefully, these limitations may be relaxed in a few years, once pattern-matching coverage has proven itself in the certification field.

[RenjiSann]

July update

In the last weeks, we started reintroducing MCDC instrumentation for boolean expressions in the rustc compiler.

Re-implementation of MCDC

The reimplementation is going well. The goal of this work is to introduce an MC/DC instrumentation like what was previously existing. However, we try to take in account the following points:

• Make the implementation as unobtrusive as possible, both in the "common" compiler code and in coverage-specific code, to avoid being a burden.
• When possible, isolate MCDC-specific code in their own files.
• Try to interact seamlessly with expansion (one of the reasons the late implementation was removed).

Implementation is going well, and should be ready in a few weeks time.

About pattern matching

As mentioned in the last update, we were considering implementing first the naive pattern matching instrumentation approach, where each check of a match candidate is a condition, and the whole candidate is a decision, while explicitly not instrumenting (and thus disallowing in certification context) or-patterns.
This implementation effort will start after standard boolean expression instrumentation is back on its feet.

[RenjiSann]

August update

The merge requests for the reimplementation of MC/DC have been published and will be reviewed soon

• MC/DC Coverage re-introduction (1/3): THIR data gathering rust#161222
• MC/DC Coverage re-introduction (2/3): MIR instrumentation rust#161223
• MC/DC Coverage re-introduction (3/3): Codegen rust#161224