rustfmt fails to resolve `mod foo;` decorated by an attribute macro

[zhoukezi]

Summary

#[my_macro] mod foo; (an "outlined" module supplied to an attribute/derive proc
macro) was recently stabilized on nightly by rust-lang/rust#157857.
In this form the module body can be provided by the macro, so there is intentionally
no foo.rs / foo/mod.rs on disk.

rustfmt, however, seems unconditionally try to resolve every mod foo; to a file
on disk and aborts the entire run when the file is missing, regardless of whether
the module is decorated by an attribute macro.

Expected behavior

rustfmt formats the file (or at least leaves the #[my_macro] mod foo; item
untouched and continues) without requiring a foo.rs file to exist on disk,
since the attribute macro provides the module body.

Actual behavior

rustfmt aborts with a module resolution error and exits non-zero:

Error writing files: failed to resolve mod `foo`: /tmp/foo.rs does not exist

Configuration

Nothing special. Nightly rustfmt.

Reproduction Steps

> cat test.rs
#[my_macro]
mod foo;
> rustfmt +nightly --edition 2024 test.rs
Error writing files: failed to resolve mod `foo`: /tmp/foo.rs does not exist

Nightly rust currently accepts this code (after replacing the placeholder with a real proc-macro that supports this syntax).

Meta

rustfmt --version:

rustfmt 1.9.0-nightly (d0babd8b6b 2026-07-15)

[ytmimi]

I had no idea that #[my_macro] was even a thing. Is rust-lang/rust#54727 the right tracking issue for this?

So basically if rustfmt sees a #[my_macro] over a module declaration then it shouldn't try to resolve it? @zhoukezi let me know if I'm understanding that correctly.

[zhoukezi]

@ytmimi

Is rust-lang/rust#54727 the right tracking issue for this?

As far as I know, rust-lang/rust#54727 is the larger tracking issue for #![feature(proc_macro_hygiene)], of which #[my_macro] mod foo; is a part. #[my_macro] mod foo; itself was discussed in rust-lang/rust#54727 (comment) and independently stabilized in rust-lang/rust#157857. I'm not entirely sure whether rust-lang/rust#54727 is the right reference in your context.

So basically if rustfmt sees a #[my_macro] over a module declaration then it shouldn't try to resolve it?

I think that would address the issue I'm running into. rust-lang/rust#157857 passes mod foo; as tokens directly to #[my_macro], so there's no reason to assume foo.rs exists on disk, or even that the macro will emit any module at all. That said, to be cautious, I'm not sure whether this would affect rustfmt's own internals or other edge cases. mod is admittedly special syntax.