Add Support for sorting `#[derive(...)]`

[maksym-arutyunyan]

Hi rustfmt team,

This idea has come up regularly since 2017 — users keep asking for #[derive(...)] traits to be sorted automatically, just like imports. And each time, it’s been closed with the same core concern: that the order of derive macros might matter, and reordering them could break things.

#1867, #4112, rust-lang/style-team#154

That concern made sense back then. But a lot has changed since.

To work around the lack of native support, several community tools have emerged:

• keepsorted – my own tool to keep blocks like derives sorted. And https://sort-derive-traits.github.io/
• cargo-derivefmt
• cargo-sort-derives

These tools are helpful, but they come with limitations. They usually operate via regex or simple token logic, which means they can't match the accuracy or safety of a proper syntax-aware formatter. More importantly, each tool may use a slightly different sorting convention, which introduces fragmentation and inconsistency across projects and teams.

Having this behavior built into rustfmt would solve both problems:

• It would ensure consistency across the Rust ecosystem.
• It would offer users a reliable, idiomatic way to enforce ordering — just like how import sorting works today.

In the last relevant discussion rust-lang/style-team#154 (comment), it was acknowledged that most of the original blockers no longer apply. The one remaining edge case — where one derive macro implicitly enables another — is:

• Extremely rare
• Easy to detect and fix (just add an import)
• A hard error at compile time, not a subtle bug

Given this, I believe it’s now safe and timely to reconsider.

Would you be open to adding support for sorting derive traits in rustfmt?
Or if there’s still a concrete reason this can’t be done safely, could you share a specific example?

Thanks again for all your work on rustfmt — it’s a tool we use and appreciate every day.

[ytmimi]

If that's the case then I'd be much more open to the proposal of sorting derives. Do you know whether or not the trait order still matters in older editions or is the order irrelevant in all editions? Also, are we absolutely sure that the only outstanding edge case is the one outlined in rust-lang/style-team#154 (comment)?

[maksym-arutyunyan]

Hi @ytmimi, thanks for the thoughtful questions!

If those were directed at me — I’m afraid I don’t know. I’m just a regular SWE using Rust at work. I found it confusing that rustfmt doesn’t sort derive traits like it does with imports, so I built my own tool (keepsorted) as a temporary workaround.

I totally understand there might be blockers for a perfect solution. But even partial support — like sorting only the most common and safe derive traits (e.g., the canonical ones from the Rust book) and leaving the rest in user-defined order — would already be a big improvement in my view.

Thanks again for considering it!

[spectria-limina]

See rust-lang/rust#79078 for the behaviour change that eliminated most order dependencies of derive attributes. I've personally checked that derive macros cannot "see" one another, and since they do not modify the original item—they can only emit new items—their behaviour cannot be changed by each other. I do not believe this behaviour is edition sensitive, but I am not 100% sure.

There are other edge cases, such as if a derive macro is ill-behaved and is whitespace-sensitive, accesses the filesystem, etc. All of those potential edge cases are already potentially going to cause problems with any reformatting, though.

As discussed in my comment in rust-lang/style-team#154, my preference would be for the remaining edge case to become a hard error in a future release. In my opinion, it's equally ill-behaved for a derive macro to bring new names into scope.

[teor2345]

Re-ordering derives impacts Clone/Copy and PartialOrd/Ord optimisations, see rust-lang/rust#124794

There's a Zulip discussion in #t-compiler > Cheap `derive(PartialOrd, Ord)`, I think there was also other recent discussions around derive specialization.