Repository navigation
attribute macro arguments #7172
Description
zulip thread: #t-rustfmt > attribute macro args
Feature Request
add an unstable option for formatting attribut macro arguments following the same rules as function-like macro arguments
i.e. #[my_macro<DELIMITED_TOKENS>] would be formatted similarly to my_macro!<DELIMITED_TOKENs> (i.e. try parsing as an expr/type/pattern if possible)
Motivation
most verification tools for rust take function contracts in the form of attribute macros (#[verus_spec(...)], #[creusot_std::macros::requires(...)] are the first examples that come to mind). their input syntax slightly differs from rust code (e.g. ==> for implication), but that's out of the scope for this issue, and can be addressed by the macro authors if needed. im currently working with creusot devs to improve the situation on this front.
because rustfmt currently skips formatting of complex expressions, the burden of formatting the specification code falls on the user and quickly becomes a chore
Related configuration options
none, to my knowledge
Activity
ytmimi commentedon Oct 14, 2026
@sarah-quinones can you post an example code snippet of code you'd like rustfmt to be able to format? I'm also not sure if this is a feature request or just a current limit in rustfmt that could be addressed.
sarah-quinones commentedon Oct 14, 2026
example code
should format the requires-clause
sarah-quinones commentedon Oct 15, 2026
would it be okay for me to open a pr with an implementation for this?
ytmimi commentedon Oct 15, 2026
Sure, I can take a look
sarah-quinones commentedon Oct 15, 2026
sweet! i'll get working on it after work
ytmimi commentedon Oct 15, 2026
Before you get started, I was wondering if you're still thinking of adding a new option for this or not? If so, could you outline how you'd expect that to work?
My initial thought is that we don't need a new option for this, but I'd like to better understand what you're thinking.
sarah-quinones commentedon Oct 15, 2026
the reason i was thinking of adding a new option is for backward compatibility but i'm fine with just making it unconditional if that's preferable
ytmimi commentedon Oct 15, 2026
@sarah-quinones we'd likely need to add a style_edition gate so that we don't introduce breaking formatting changes on a stable release channel.
In addition to the
style-editiongate we could also consider adding anightly-onlycheck that could enable the formatting too. We have a similarnightly-onlycheck in place forcfg_select!while we're trying to nail down that formatting implementation.