Skip to content

Commit db08cd6

Browse files
PLeVasseurPLeVasseur
authored
meeting: coding guidelines agenda for 2026-04-01 (Safety-Critical-Rust-Consortium#615)
* meeting: coding guidelines agenda for 2026-04-01 * add notes
1 parent 8fa32c2 commit db08cd6

1 file changed

Lines changed: 146 additions & 0 deletions

File tree

  • subcommittee/coding-guidelines/meetings/2026-04-01

‎subcommittee/coding-guidelines/meetings/2026-04-01/minutes.md‎

Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
# **Coding Guidelines Subcommittee Meeting on 2026-04-01 @ 1600 CEST / 1100 EDT**
2+
3+
[Link](https://www.worldtimebuddy.com/?qm=1&lid=5,12,2643743,8,1850147,100,14&h=5&date=2026-4-1&sln=11-12&hf=1) to meeting time in common time zones.
4+
5+
| Search Key | Description |
6+
| :---- | :---- |
7+
| \[todo\] | Action Item |
8+
| \[decision\] | Something decided on |
9+
| \[important\] | Key information |
10+
11+
## **Agenda**
12+
13+
1. Solicitation of notetaker
14+
2. Acceptance of [Previous Meeting Minutes from last instance](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/subcommittee/coding-guidelines/meetings/2026-03-25/minutes.md), [Previous Meeting Minutes from last Asia Pacific \+ Americas meeting](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/subcommittee/coding-guidelines/meetings/2026-03-27/minutes.md)
15+
3. Introduction of new members
16+
4. Overview of [Safety-Critical Rust](https://rust-lang.github.io/rust-project-goals/2026/roadmap-safety-critical-rust.html) \- Rust Project Goals Roadmap (Pete)
17+
- Soliciting those interested in [Establish a Spot for Safety-Critical Lints in Clippy](https://rust-lang.github.io/rust-project-goals/2026/safety-critical-lints-in-clippy.html) goal
18+
- Great way to get mentored and onboarded if interested in Clippy
19+
5. Macros chapter rework (Alex)
20+
6. Review batches for [CERT C \=\> Rust Mapping](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/336) (David)
21+
- [\#427 \[CERT C Review Batch 1/5\] Review proposed Rust categorization](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/427)
22+
- [\#428 \[CERT C Review Batch 2/5\] Review proposed Rust categorization](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/428)
23+
- [\#429 \[CERT C Review Batch 3/5\] Review proposed Rust categorization](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/429)
24+
- [\#430 \[CERT C Review Batch 4/5\] Review proposed Rust categorization](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/430)
25+
- [\#431 \[CERT C Review Batch 5/5\] Review proposed Rust categorization](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/431)
26+
7. Coverage of MISRA C and CERT C in 2026 (Félix / Markus)
27+
- MISRA C one has a [PR up](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/432) from Markus
28+
- Félix wanted the review batches done first IIRC; also not feeling well so we pause
29+
8. Proposals and ideas for new rules (all)
30+
9. Progress on ongoing tasks (all)
31+
10. Round table
32+
33+
## **Check-in area**
34+
35+
**Please add your name, and an emoji that describes your day.**
36+
37+
* David Svoboda (-:
38+
* Samuel Wright 😷
39+
* Pete LeVaseur 🍵
40+
* Douglas Deslauriers 🖌️
41+
* Max Jacinto 🍕
42+
* Markus Hosch 👽
43+
* William Barsse
44+
* Christof Petig 🚲
45+
* Arshad Mahmood 🕺
46+
* Oreste Bernardi🏥
47+
* Alex Celeste 🍵
48+
49+
**Notetaker:**
50+
51+
* Alex Celeste \+ Pete
52+
53+
For tips on how we take notes in the Safety-Critical Rust Consortium, please see the [Meeting Notetaker Role](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/docs/notetaker-role.md) doc.
54+
55+
## **Housekeeping section**
56+
57+
* Document space: [coding-guidelines](https://github.com/rustfoundation/safety-critical-rust-consortium/tree/main/subcommittee/coding-guidelines)
58+
* Zulip: [safety-critical-consortium: Coding Guidelines](https://rust-lang.zulipchat.com/#narrow/channel/445688-safety-critical-consortium/topic/Coding.20Guidelines)
59+
* [Kanban board](https://github.com/orgs/rustfoundation/projects/1/views/3)
60+
* [`contributor experience`](https://github.com/orgs/rustfoundation/projects/1/views/4) view
61+
* [`coding guideline`](https://github.com/orgs/rustfoundation/projects/1/views/5) view
62+
63+
## **Tasks**
64+
65+
* \[todo\] Pete: post the invitation to participate in writing Clippy lints to Zulip
66+
* \[todo\] request Felix’s opinion of the comments that have been added, when he is available and not before
67+
* \[todo\] Pete to put out the list of available spaces for the Rust Week meeting; anyone interested in going, to contact Pete to claim one of them
68+
69+
## **Meeting Minutes**
70+
71+
* Safety-Critical Rust Roadmap \- brought under the purview of the Rust Project, four current goals listed but more can be added
72+
* Place any new items into a sequence leading into 2027, 2028
73+
* Opportunity for anyone wanting to get involved with the Project / interested in static analysis / interested in Clippy:
74+
* Task to take Guidelines produced by the Subcommittee and turn them into actionable, configurable lints
75+
* Reach out to Pete; room for 2-3 people to get hands-on mentoring \[a couple of volunteers express interest in the room\]
76+
* Macros chapter cleanup
77+
* Sitting there in “be provocative” and “force documentation of features” way
78+
* Curious to see if there are directions folks would like to see it move in
79+
* E.g. if interested in auditability
80+
* Forbidding / subsetting today is suitable in a sense
81+
* Some thoughts that in ISO 26262 ASIL D it’s probably fine to forbid macros
82+
* Use generated macro code and run the same sorts of analysis on them as normal Rust code
83+
* We could be more specific or be more broad
84+
* Are we okay with “you shall not use macros” and encourage using the generated code instead?
85+
* Kind of okay with this; could treat this more as a tool rather than a language construct
86+
* Test of our feedback mechanism/exception writing process of the guidelines to start dialog with users
87+
* Macros in C vs Rust
88+
- with C you can get the exact code out of the preprocessor
89+
- with Rust that’s not necessarily the case
90+
- might need new compiler extension to test this correctly
91+
* If using many macros, this could become onerous and painful
92+
- feedback that one commercial tool does this check of whether the macro-generated code doesn’t change the meaning
93+
- check that the code does the same thing before/after macro expansion
94+
* Useful tool that could be looked into:
95+
- [https://github.com/scrabsha/cargo-hexpand](https://github.com/scrabsha/cargo-hexpand)
96+
* What about projects where macros are used? Heavily?
97+
* e.g. a project using mantra for traceability
98+
* would this require deviation at each point of expansion?
99+
- No, not necessarily; could be kind of a “blanket” deviation
100+
* It would be up to the auditor whether or not they agree it would be justified to deviate once for all uses of that one specific macro
101+
* Nightly compiler required for macro expansion
102+
* Usage of standard library is kind of a separate concern, if using e.g. `println!(..)`
103+
* Usage of tools
104+
* How easy/hard it is to mitigate issues with tools
105+
* How impactful any issue with tool
106+
* Can derive Tool Confidence Level (TCL)
107+
* MISRA has [“MISRA AC”](https://misra.org.uk/misra-autocode/) as a separate standard
108+
* `fmt!()` and friends are a part of libcore; could be already a part of some newly safety-certified code coming up
109+
* For ASIL D restricting usage of macros can make sense; for ASIL B it seems to be too restrictive
110+
* Macros are important for variable number of arguments; not possible with functions currently
111+
* Feedback from Eclipse S-CORE:
112+
* If inspecting macro output itself doesn’t work this is a challenge
113+
* Different levels of ASIL have different rules; differences between e.g. ASIL B, D
114+
* Some issues with this in practice if the coding guidelines are not explicit
115+
* required is fine so long as project-wide justifications for Deviations are provided: in practice this is accepted by ASIL-D
116+
* Summary of section: distinction between writing and expanding macros
117+
* Required axis for writing macros, esp proc
118+
* Required axis for using macros, with the possibility of Deviation at either an expansion site or by macro name
119+
* Safety level \- too restrictive for the lower (e.g. ASIL A, B) safety levels to ban them all but this will test our ability to follow up
120+
- Want the ability to tag guidelines as relevant to specific safety level user profiles
121+
- Onerous for more idiomatic uses of the language and its direction of evolution
122+
* Specific exceptions can be directly integrated into the guidelines for known named macros or builtins
123+
* Review of the CERT C mapping
124+
* Three out of the five “buckets” were examined last week; the table for each bucket has been reviewed by David with comments added where necessary (comments not added when they didn’t add anything but all mappings reviewed)
125+
* For example, once comment added on the fifth bucket to add missing context on a specific rule (DCL37-C)
126+
* Tables are not yet fully updated \- not many comments to address which might change them
127+
* Additional feedback comments can be added offline
128+
* Further actions pending Felix’s availability
129+
* MISRA C 2023 has an Addendum with a mapping to CERT C; this content will also be imported to CERT C itself
130+
* Some possible discrepancies on things like the definition of “decidable” (MISRA “decidable” approximately equals CERT “detectable”)
131+
* Andrew Banks / David Ward declined permission to use the MISRA C rule headlines
132+
* Possible arrangement to be made in future but not currently for use in public
133+
* CERT C may have permission to use the titles (unclear where this came from)
134+
* Rule numbers are always OK to use
135+
* Hopefully not a huge problem in practice for readability
136+
* MISRA C++ committee producing an equivalent to MISRA C ADD6
137+
* Alex brought this to them; got the “okay” for it being signed off on by the C++ experts
138+
* Someone from the Rust world would need to write it, they had not agreed on writing it as they are not Rust experts
139+
* Another potentially useful tool for credibility with auditors etc.
140+
* Free spaces in the Rust Week meeting (see todo)
141+
* Some of the free spaces can be used for non-SCRC members who are already at Rust Week and may want to participate
142+
* Adjourned.
143+
144+
## **Material**
145+
146+
Any material to read before the meeting should be included here.

0 commit comments

Comments
 (0)