Rust SIG Meeting - 2026-05-12 #27

PLeVasseur · 2026-05-12T13:27:33Z

PLeVasseur
May 12, 2026
Collaborator

Hey folks 👋 welcome to our 9th meeting of 2026.

Rust SIG Meeting 2026-05-12

Agenda

Solicitation of notetaker
- Pete LeVasseur
Rust Watercooler Chat Topic - Rust for ASIL D - are we there yet?; Alex Senier - Ferrous Systems
Review GitHub repo content and discuss how to enrich (Pete)
1. Issues
2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
Office hours - Rust + Automotive questions - come chat! (All)
Discuss upcoming events / news related to Rust & Automotive (All)
Meeting close

Check-in area

(We had ~19 people around at one point at max)

Housekeeping section, please add

Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
GitHub repo: https://github.com/rust-sig/rust-sig
Eclipse SDV Slack channel: #rust-sig

Tasks

Meeting Minutes

Rust for ASIL D - are we there yet?; Alex Senier - Ferrous Systems

Are we there yet?

Yes! * - caveats to come later

Alex is working as Head of Product & Engineering @ Ferrous Systems

A lot of overlap on what is needed / required for various domains: industrial, automotive, medical

Question / survey to attendees: ASIL D with Rust: Are we there, yet?

Yes, soon: 4
No, but by 2027: 1
No, but by 2028: 4
No, but by 2030: 1

Question / survey to attendees: What's your timeline for ASIL D?

Never (I don't do / won't need ASIL D): 1
2026: 1
2027: 3
2028: 3
2029: 1
2030: 1
later: 1

Status quo for ASIL D today

Ferrocene Compiler: ASIL D
Ferrocene libcore subset: ASIL B
libstd, external crates, user software, ... : falls outside, currently

Question: Reasons for libcore for only ASIL B? Blocking points?

Some financial, some capabilities
Elephant in the room: Modified Condition / Decision Coverage (MC/DC)

MC/DC Solution Space

Spans across two dimensions
- Source/Binary
- Instrumentation / Trace-based / Static analysis
Source + Instrumentation:
- Through branch coverage
  - If you structure conditions in the "right way" for short-cutting part as the first part of the condition
  - "Simple" according to certain rules
  - Then arrive at MC/DC == branch coverage
  - One problem is that branch coverage is not stable at the moment either
  - Could be cases in e.g. libcore where the code is not written in this way
- Sanitizer Coverage
  - Implemented in LLVM
  - Inserts calls to user-defined functions and track blocks and edges
  - Theoretically able to do coverage using it
  - Haven't yet looked at it closely yet; could be some kind of useful shortcut in the near term
- rustc
  - The end goal would be having MC/DC implemented in rustc
  - MC/DC only needed to the highest levels of safety, so how many features are needed upstream?
Source + Instrumentation
- Assembly Instrumentation
  - Done in C as well; add instrumentation to branches
  - Certain challenge here may exist for deploying the instrumented binaries to production, hardware-constrained systems
Source + Static analysis
- Manual
  - Very "simple", but could be large effort and not practical for most real-world software
  - Maybe the volume of ASIL D code is quite small; might be worth it for certain cases
- Symbolic Execution
Binary + Trace-based
- Hardware Tracing
  - Similar in nature to Source + Instrumentation
  - Benefits because the full implementation does not need to live in the final binary
- Virtualization
  - Similar in nature to Source + Instrumentation
  - Benefits because the full implementation does not need to live in the final binary

Call out for source-based traces from the group to see if anyone knows of this; macros in Rust?

Theoretically possible, seems to lead to macros everywhere, perhaps?
Note from attendees: use tooling to identify branches, then add traces, then pass onto the Rust compiler?
- Maybe possible; could run into issues with macros.
- Due to macro hygiene in Rust, you cannot maybe perform the same as in C by running the pre-processor.
- Note from attendee: Nothing in original source code, but something which would transform the source. Does this fall under some other category than tracing?
- Then have to qualify the tool to ensure that the semantics are maintained from before/after running the tool. Source-based instrumentation.
- Rather might be closer to something like Miri: transform, run through interpreter to observe what the code is doing, maybe?

Question: MC/DC on complete library: complex?

Application which uses only a portion of the library
Might be able to run MC/DC only on that portion?
Since we don't certify the whole library, only the application and the portion of the library which is used
Clarification: subset of libcore is certified at the moment
Ferrocene driven by customer needs often currently, so as customers have needs this can grow the subset which is certified
For example, not very useful pieces to start with: panic handling / unwinding if you are intending to write software which should not panic

Question: what parts of Rust need to be covered by MC/DC to be considered "usable"?

Attendee: Minimum -- pattern matching must be there. Widely used, considered idiomatic, often required for typical ways of writing Rust and utilizing Rust's advantages
Agreed; pattern matching missing in Rust would be pretty annoying. Lose out on checking completeness of matches that's a nice safety feature of the language.
How about guards in match statements?
- Attendee: Can we transform guards?
  - Attendee: Seems possible to do the transform to "with" => "without guards".
- Attendee: People might be able to live without it. Base pattern matching seems to be the minimum.
- Seems like an interesting discussion point: how much should people need to "bend" their code to be workable with the tool?

Question: I hear the argument for baking MC/DC into the compiler, but what's the actual technical blocker for external tools? Is it that they can't see the Control Flow Graph as clearly as the MIR does?

AdaCore has posted up some of their thoughts on why/why not to do the MC/DC within the compiler over on this thread on the Rust Zulip: #project-goals/2026-workshop > mcdc-support

Note: If we have to come with a new language, new way of doing things, and say that we don't need an expected thing, like MC/DC then the assessor will need some good rationale

Attendee: Want to understand MC/DC measure.
Attendee: Hypothetical: If you're a teacher, then you are trying to figure out how much students have learned. If the tradition is to do some sort of written test, it can be easy to confound the duty as a teacher to "learn at least X things, to Y level of proficiency" with "I have to do this exact test that has been the tradition for the last Z years".
- Attendee: The goal of MC/DC is not to "do MC/DC", but figure out what the goal might be and argue to it for other means.
Could find another way of doing things, but an option we should not rule out is to "simply do MC/DC" to make life of assessor easier to check the box and do what's familiar and comfortable.
https://arxiv.org/abs/2409.08708 paper for MCDC by Ferrous Systems

Question: What's blocking now: writing exhaustive tests for the core library or measuring the MC/DC in Rust?

Writing tests is possible today
Measuring the coverage via MC/DC today is the challenge
Not prevented from doing manual truth table efforts, but it's a strawman
- If even done for subset of libcore, then would have to be done for any users of libcore in application software

Other items needed:

... insert list here...
Bindgen qualified
Company policies
- Attendee: Large companies have well-established processes for C, C++, but not Rust. If starting certification process, would have hiccups in the organization and policies
- Familiarity with a new thing; whether in company, the assessor. Not a technical problem to solve.
- Ferrous Systems has a requirements tracing tool for Rust: mantra
  - Might get this qualified as well

From Alex's list

Stack-depth: a big item in avionics

Yes, ASIL D is possible today

bare metal
no core library
potentially a lot of not fun

Question: Would a manual truth table be accepted by an assessor?

Tricky to answer, unless/until someone tries
Gut feeling is that the answer might be "yes"
- two independent reviewers validating the truth table

Formal verification since 2009

Mostly been using SPARK subset of ADA and associated tooling
Still keep trying to convince people of the formal verification, even with very well-proven tools
Rust is better positioned here as many things we used to call formal verification are just built into the Rust compiler: alias checking, borrow checking
Formal verification gets somewhat of a bad wrap as people need a PhD to understand and use it effectively

Question / survey to attendees: What's missing (only!) for ASIL D?