rustfmt emits non-compiling code by removing tokens from function-like macro invocations

[crescmoon]

Summary

Rustfmt strips the parameter names out of macro invocations whose arguments happen to look like function calls. The resulting code does not compile despite rustfmt returning 0.

I tried to format this code:

macro_rules! my_macro {
    ($name:ident ( $($arg:ident : $ty:ty),* ) -> $ret:ty) => {
        fn $name($($arg: $ty),*) -> $ret { todo!() }
    };
}

my_macro!(f(x: &str) -> ());
my_macro!(g(n: i32, m: usize) -> usize);

fn main() {
    f("Hello world!");
    g(42, 2026);
}

Expected behavior

I expected to see this happen: the invocations are left as written.

my_macro!(f(x: &str) -> ());
my_macro!(g(n: i32, m: usize) -> usize);

Actual behavior

Instead, this happened: the parameter name is dropped (cargo +nightly fmt does this, while cargo fmt does not).

my_macro!(f(&str) -> ());
my_macro!(g(i32, usize) -> usize);

The result does not compile, since the token stream no longer matches the macro's matcher:

error: no rules expected `&`
 --> src/main.rs:7:13
  |
1 | macro_rules! my_macro {
  | --------------------- when calling this macro
...
7 | my_macro!(f(&str) -> ());
  |             ^ no rules expected this token in macro call
  |
note: while trying to match `)`
 --> src/main.rs:2:45
  |
2 |     ($name:ident ( $($arg:ident : $ty:ty),* ) -> $ret:ty) => {
  |                                             ^

error: no rules expected `,`
 --> src/main.rs:8:16
  |
1 | macro_rules! my_macro {
  | --------------------- when calling this macro
...
8 | my_macro!(g(i32, usize) -> usize);
  |                ^ no rules expected this token in macro call
  |
note: while trying to match `:`
 --> src/main.rs:2:33
  |
2 |     ($name:ident ( $($arg:ident : $ty:ty),* ) -> $ret:ty) => {
  |                                 ^

error: could not compile `main` (bin "main") due to 2 previous errors

No additional configuration is required to reproduce this. Both rustfmt +nightly --edition 2024 src/main.rs and cargo +nightly fmt result in this change.

Meta

Version it worked on

It most recently worked on the following versions:

rustfmt 1.9.0-stable (8bab26f4f6 2026-07-14)
rustfmt 1.10.0-nightly (771916f902 2026-08-08)

Version with regression

rustfmt +nightly --version:

rustfmt 1.10.0-nightly (969b803cbe 2026-08-09)

rustc +nightly --version --verbose:

rustc 1.99.0-nightly (969b803cb 2026-08-09)
binary: rustc
commit-hash: 969b803cbe1d4499f841ae0a49c637d8c70a0458
commit-date: 2026-08-09
host: x86_64-unknown-linux-gnu
release: 1.99.0-nightly
LLVM version: 23.1.0

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[crescmoon]

The bisection points to rust-lang/rust#160789, a rollup merge of 5 PRs. rust-lang/rust#158517 is my best guess due to it changing the parser, but I couldn't confirm it.

searched nightlies: from nightly-2026-08-09 to nightly-2026-08-10
regressed nightly: nightly-2026-08-10
searched commit range: rust-lang/rust@771916f...969b803
regressed commit: rust-lang/rust@153ecc4

bisected with cargo-bisect-rustc v0.6.11

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2026-08-09 --end=2026-08-10 --script=bisect.sh --component=rustfmt --access=github --preserve

bisect.sh:

#!/bin/bash
rustfmt --edition 2024 --check src/main.rs

src/main.rs is the snippet in the issue body.

[JonathanBrouwer]

@rustbot claim
This is indeed almost definitely rust-lang/rust#158517, I'll take a look sometime in the next few days

[ytmimi]

@JonathanBrouwer Thank you!