[Rust Goals 2027] Macro safety

[pellico]

This is tracking issue regarding potential topic to be discussed with Rust project. (Rust Safety Coding Guidelines meeting 4/3/2026)

Rust macro can generate a lot of code and it is straightforward to guarantee the correctness in safety critical application:

There are two main line of reasoning:

1. Expand macro and apply the same guidelines and process for generated code (e.g. test coverage, delta review ...).
   This is a accepted method for C macro and other code generator but it requires that expanded code can be compiled with same semantic.
2. Apply strict macro guidelines and usage limitation.
   This doesn't require any technical change in Rust tooling but there is not yet a wide agreement that by just coding guidelines is possible to guarantee code correctness.

Personally I prefer the first solution because it is the most convincing and easy to justify but it looks like that this requires a significant change in the Rust compiler.

[felix91gr]

This is a accepted method for C macro and other code generator but it requires that expanded code can be compiled with same semantic.

@pellico what do you mean that it can be compiled with the same semantic?

For what it's worth, this is how macros look like from the POV of the compiler:

1. Macro declaration: a macro's source code is used for expansion, but since it is uncallable at runtime, this code is not part of the final binary.
2. Macro invocation: a macro's invocation and intermediate expansions (in the case of a declarative macro) are always valid Rust syntax, but aren't necessarily valid Rust semantics.
3. After a macro has been expanded: the code that remains after fully expanding a macro, assuming it compiles, is normal Rust code.

My guess is that you're describing (3): the code that remains after a macro has been fully expanded. That code is semantically just Rust code, and is compiled with the exact same semantics as every other piece of Rust code.

---

Regarding:

2. Apply strict macro guidelines and usage limitation.

I'm more and more convinced that macro guidelines are largely a red herring. Macro code is so small in volume compared to the rest of the code, that instead of a guideline that addresses macro code, we might be better off asking people to document and audit their own macros. It's so little code, relatively speaking, that it might be cheaper and more effective to justify each individual macro declaration than it would be to write general coding guidelines for macro code.

---

An extra point you might be interested in: macro hygiene.

• Declarative Macros are partially hygienic
• Declarative Macros 2.0 will be fully hygienic

[pellico]

@felix91gr

My guess is that you're describing (3): the code that remains after a macro has been fully expanded. That code is semantically just Rust code, and is compiled with the exact same semantics as every other piece of Rust code.

Yes. This is what I meant.
But as stated here and in cargo-expand it not guarantee that if I take the source code after full macro expansion to text the recompiled text code has the same behavior.

I'm more and more convinced that macro guidelines are largely a red herring.

Regarding macro guidelines. (by the way I mean declarative & procedural macros) I agree that they are not the right solution. I wrote down this solution because during a coding guidelines was asked me to keep track of this discussion with an issue and list all proposal.

Depending on the project the content can be a lot. e.g (RTIC) [https://rtic.rs/2/book/en/]. I don't think that relying only on some macro code review is enough for high reliability application. e.g. ISO26262 ASIL D. (that requires --> test coverage, MD/DC coverage .... ).

If you mean to propose macro review only for declarative macro I still think we need to describe some rule or limit to the complexity of the macro.

TL;DR

Safety critical consortium should answer to following questions:

1. Can we use macros in safety critical application ?
2. If yes, which are the constraints ?
3. Is there anything shall be done by the Rust Project ?

My personal answer/proposal to these questions are:

1. Yes
2. Expand the macros to text code. Apply to them all process/guideline planned for regular Rust code e.g. (test coverage, md/dc, coding guidelines...)
3. Yes. A method to expand the code to text that preserve the behavior or in other words solve the limitation described in here and in cargo-expand

However maybe there are simpler and more convincing argument for safety assessor.

[felix91gr]

@pellico I brought more things that may help! I still have to give you a proper response on the rest of your message, which I hope to be doing shortly :)

I've found a handful of things that complement this topic, in the sense that they take away some of the cognitive and maintenance load of macros. They are part of the proposed goals for 2026.

Belonging to the roadmap of "Constify all the things"

Broad roadmap: Constify all the things

It aims to reduce the need for Proc Macros with more fully-featured const generics, const evaluation and reflection.

Specific goals in the roadmap:

1. reflection and comptime: to add the building blocks necessary for reflection to be available on arbitrary types without them needing to #[derive(...)] anything in upstream.
2. Full Const Generics: to complete the feature set of const generics. This will eliminate the need to use macros to construct compile-time-value-determined types, while also giving stronger and earlier guarantees of their correctness.
3. Const Traits: to lift the limitation of const fn that doesn't let them call trait methods.

Independent Goals

Declarative Macro improvements: to make Declarative Macros capable of replacing Derive and Attribute Macros, which are currently only available as Procedural Macros on stable.

---

All of these should lessen the maintenance burden of macros, and lessen the need for procedural macros (which are most often the hardest ones to reason about and audit).

[felix91gr]

Depending on the project the content can be a lot. e.g (RTIC) [https://rtic.rs/2/book/en/].

Okay fair enough, RTIC seems to be using a lot of proc macros: https://github.com/rtic-rs/rtic/tree/master/rtic-macros/src

I see three caveats to that though:

1. In my last message prior to this one, I linked to a handful of initiatives which should make most of this macro code obsolete. Full Const Generics and Const Traits will eliminate an entire class of macros that are required nowadays for constructing types as function of compile-time values. For the macros that are still required, the reflection and comptime goal will enable them to reason about code from type information instead of just token streams: this will make proc macros significantly easier to write and validate. And finally the Declarative Macro improvements goal should make Proc Macros less and less relevant. Declarative Macros tend to be easier to validate, and for very common use cases such as Derive and Attribute macros, they are often better suited than Proc Macros.
2. This example is of a library, and quite a large one at that. This means that it will have more macro code than most other projects, which makes it a bit of an outlier. Furthermore, it has quite a bit of code in general; not only macro code. So any auditing effort would require a lot of resources just because it is a large project.
3. On the other hand, projects like these have communities behind them, and thus usually have access to more and better auditing resources than individual embedded projects. I'm sure RTIC is capable of getting the resources necessary to certify itself once it is more feature-complete.

I don't think that relying only on some macro code review is enough for high reliability application. e.g. ISO26262 ASIL D. (that requires --> test coverage, MD/DC coverage .... ).

Macros can be tested, for sure. But I'm not sure if MC/DC makes much sense in the context of macros.

As an aside: those standards will probably need new chapters for macros like these, since neither C nor C++ have anything like them. C's macros are barely macros at all, and C++'s templates are closer to a const-generics language feature, but executed with terrible ergonomics.

If you mean to propose macro review only for declarative macro I still think we need to describe some rule or limit to the complexity of the macro.

I went and asked the macro experts in Zulip: https://rust-lang.zulipchat.com/#narrow/channel/404510-wg-macros/topic/What.20would.20you.20say.20makes.20a.20Decl.2E.20Macro.20hard.20to.20maintain.3F/with/560269473

I'm not sure there is any rule we can write that would be useful for macro maintainers or auditors. I want to say yes, but we have to consider that:

1. Declarative Macros are Turing Complete, which makes it undecidable to enforce any non-trivial rule about macros (as per Rice's Theorem).
2. We don't want to get in the way of people who know what they are doing either. We want to make rules that help people make good macros; not rules that force people to make bad code.

---

Safety critical consortium should answer to following questions:

1. Can we use macros in safety critical application ?

2. If yes, which are the constraints ?

3. Is there anything shall be done by the Rust Project ?

Let's see how we match :)

My personal answer/proposal to these questions are:

1. Yes

Yeah, I agree here. This is pretty obviously something we want to have.

2. Expand the macros to text code.

This is something that happens already with macros: macros are expanded early in the compilation process, at their call sites. Their own source is never used for binary code generation.

You can think of code that uses macros basically like normal code - for almost all static analysis tools, the input code is already post-macro-expansion.

Apply to them all process/guideline planned for regular Rust code e.g. (test coverage, md/dc, coding guidelines...)

I think I see what you mean. Hmm. Yeah, I think most of those could be applied for macro-expanded code.

So perhaps your answer to Question 2 also implies that we need more and better tooling to reason about macros.

That would be my constraint:

• We need better tools to reason about macro-expanded code.
• We also want better tools to reason about pre-expansion macro code.

3. Yes. A method to expand the code to text that preserve the behavior or in other words solve the limitation described in here and in cargo-expand

This goes in hand with my answer to (2).

Something that I would ask of the Rust Project is what is being done in the links I posted above. In particular, I mean the 2026 Goals.

With completed Const Generics, many things that require proc macros today will be expressible in the type system. This will make reasoning about them easier and it will let the programmer express their intent a lot more fully.

Reflection will make for better and more understandable proc macros. It will also the maintenance burden they impose on the programmer.

And the Declarative Macro improvements will make many "obvious" Derive and Attribute macros easier to write, maintain and understand.

Those three things will lower the need for macro code, and will make it possible to write better macro code which will be easier to maintain.

CC @pellico

[cpetig]

(discussed on today's SCRC meeting)

I just remembered the three main reasons to use macros, especially for ADAS (medium criticality)

• format_args helps a lot for debug and trace
• variable number of arguments are only possible with macros
• serialization and deserialization with proc macros is far better to get right than by doing it by hand

I agree that const generics will solve all these things in a more predictable and safer way, but this isn't available today.

[felix91gr]

@cpetig

variable number of arguments are only possible with macros

I believe that variadic functions might not be possible with the current const generics goals. I'm going to ask around though, but I think that's just outside the edge of what the current design aims to cover. (I think this is fine, since const generics on its own is a large enough goal).

format_args helps a lot for debug and trace
serialization and deserialization with proc macros is far better to get right than by doing it by hand

I agree that const generics will solve all these things

For these two, maybe you meant the declarative macros, comptime and reflection stuff?

in a more predictable and safer way, but this isn't available today.

Indeed.

I guess it all depends on how soon we want these features to be covered. From there, we might be able to assess if it's worth it to make rules that will be subsumed by them later.

From what I can tell by looking at the Project Goal pages, all the goals apart from the reflection one, are intended to be completed over this year. Using the other goals, these use cases should become a lot easier to write correctly and verify by the end of 2026:

• Constructing types as a function of compile-time values (via const generics)
• Serialization and Deserialization, and other such Derive and Attribute macros (via the Declarative Macro improvements)

For format_args, we might be looking at a 2028 feature. I will ask about this, but it seems to me like this requires some completion of the comptime + reflection goal

For variadic functions, I don't think variadic generics are going to come to the language any time soon. They might eventually be added to Rust, but I suspect that's going to be done after all of the quoted goals have been completed. So that might be post-2028.

---

Addendum: homework for me

• Ask if variadic generics are a part of the const generics design (I'm 99% sure it isn't, but I can ask the person in charge and she'll know for sure).
• Ask about how the needs of format_args are intended to be covered in the future (its final form might be a combination of const generics + variadics, but I suspect it's simpler than that).

[felix91gr]

Update (CC @cpetig)

Variadic Generics are definitely not part of the Const Generics goal. Folks would like to have it eventually, but the current goal is to get over the hurdle of completing just the compiler's ability to reason about const generic type parameters, and for the user to be able to use this ergonomically.

[felix91gr]

Okay, @cpetig I've got cool news. I asked around and I learned that format_args is a built-in construct of the compiler.

That is:

• It gets called like a macro.
• It has a declarative macro's signature.
• But it's actually a compiler built-in:

macro_rules! format_args {
    ($fmt:expr) => {{ /* compiler built-in */ }};
    ($fmt:expr, $($args:tt)*) => {{ /* compiler built-in */ }};
}

It has also been certified recently, as it belongs to the subset of core that Ferrous Systems certified under IEC 61508 (SIL 2):

• Certification announcement at Ferrous Systems
• Signature of format_args in Ferrocene's source
• Expansion of format_args in Ferrocene's source

There are a handful of other such macros, which are compiler built-ins. I'll see if I can make a list of those*. Certifying them (like Ferrous has been doing) is probably the way we will want to get assurance, as they are not technically macros. They are language primitives in the same way that bool is.

*: (updated) I've just checked and I think there are no other "macros" with the level of usage and apparent complexity that format_args has. To find all such macros, open rustc/library locally and search for #[rustc_builtin_macro] within it.

[pellico]

It has also been certified recently, as it belongs to the subset of core that Ferrous Systems certified under IEC 61508 (SIL 2):

Certification announcement at Ferrous Systems
Signature of format_args in Ferrocene's source
Expansion of format_args in Ferrocene's source

@felix91gr do you other evidence that this macro is certified ?
in my experience regarding C standard library, vendor keep in standard library all functions and in a separate document (safety manual) they write if the function is certified and under which conditions. Vendor of std library can mix different level in the same library.

[felix91gr]

If I understand how Ferrocene (the certified toolchain) works, then it (this macro) being in the source for Ferrocene should imply it was certified.

But I don't know the exact details, so I'll summon @plaindocs as he works at Ferrous and can probably explain (or knows who to ask all the questions to, if not)

[plaindocs]

Hey folks, thanks for the summons @felix91gr . Let's see if I can help.

• Ferrocene the compiler is qualified to various levels and standards as described in https://public-docs.ferrocene.dev/main/safety-manual/scope.html
• Ferous more recently certified a subset of the core library again, to various levels and standards https://public-docs.ferrocene.dev/main/certification/core/safety-plan/scope.html
• The safety manual covers how you can use both, and what the restrictions and conditions are.

format_args is however not included in that subset according to https://public-docs.ferrocene.dev/main/certification/core/safety-report/subset.html#subset

Also there is this regarding macros specifically https://public-docs.ferrocene.dev/main/certification/core/safety-plan/tools.html#macros

[pellico]

@plaindocs Thank you very much for your input.
Regarding macro there is also this

I understand from Ferrocene safety manual that regarding macros it requires to treat the generated code as regular code. (--> testing coverage, code review, coding guidelines).

Therefore I think that it would be very helpful if Rust project could provide a feature that allows full macro expansion and the code generated after full macro expansion can be compiled preserving the same semantic.
See previous posts.

[felix91gr]

@pellico sorry it took me so long. Now I get what you meant at the beginning by "macro expansion not preserving the same semantics".

You meant like the example in dtolnay's crate:

fn f() -> i32 {
    let x = 1;

    macro_rules! first_x {
        () => { x }
    }

    let x = 2;

    x + first_x!()
}

Which will return 3 when called, but when expanded "naively", which is what the crate does (and is what the cargo flag for expansion does), it will return 4.

I'll ask around. I think the tool could at least be improved.

The reason why all of this happens, as I understand it, is that declarative macros have mixed-site hygiene: https://lukaswirth.dev/tlborm/decl-macros/minutiae/hygiene.html

So... I'll get back to you on that one.

[aytey]

You meant like the example in dtolnay's crate:

fn f() -> i32 {
    let x = 1;

    macro_rules! first_x {
        () => { x }
    }

    let x = 2;

    x + first_x!()
}

Which will return 3 when called, but when expanded "naively", which is what the crate does (and is what the cargo flag for expansion does), it will return 4.

This test-case was actually fixed (by me) in rust-lang/rust#153308.

If you expand this with a nightly build that contains rust-lang/rust@bcf3d36, you'll actually have enough macro context information to work out that the invocation of first_x!() does not correspond to the shadowed x (which has the value 2).