`--check` reports "Error writing files" for a module resolution error without writing source files

Summary

When rustfmt runs with --check and encounters a module resolution error, it prefixes the diagnostic with:

Error writing files:

This wording is misleading in check mode because --check does not write formatted output back to the source files. It determines whether formatting would produce changes.

The module resolution diagnostic itself is correct. The confusing part is specifically the top-level Error writing files prefix.

This is related to #5167, which was fixed by #5243. That change corrected the module resolution diagnostic when both module.rs and module/mod.rs exist. This report concerns the top-level prefix used while rustfmt is running in check mode.

I tried to format this code:

mod responses;

with both of the following module files present:

src/responses.rs
src/responses/mod.rs

Expected behavior

I expected rustfmt to report the module resolution error without implying that it attempted to write source files.

For example, a mode-independent prefix could be used:

Error formatting files: failed to resolve mod `responses`: file for module found at both ".../src/responses.rs" and ".../src/responses/mod.rs"

A check-specific prefix could also be used:

Error checking files: failed to resolve mod `responses`: file for module found at both ".../src/responses.rs" and ".../src/responses/mod.rs"

The command should continue to exit with a non-zero status.

Actual behavior

Instead, rustfmt reports:

Error writing files: failed to resolve mod `responses`: file for module found at both "/tmp/rustfmt-check-error-repro/src/responses.rs" and "/tmp/rustfmt-check-error-
repro/src/responses/mod.rs"

The command exits with status 1.

I compared the hashes, sizes, and modification times of all three source files before and after running the command. None of the files changed.

The same behavior is present in stable rustfmt and in rustfmt built from the current main branch.

Configuration

rustfmt cli options used:

$ cargo fmt --all -- --check

rustfmt configuration file:

No rustfmt.toml or .rustfmt.toml file was present.

Reproduction Steps

1. Create a new library crate:

   cargo new rustfmt-check-error-repro --lib
   cd rustfmt-check-error-repro
   

2. Declare an external module:

   printf 'mod responses;\n' > src/lib.rs
   

3. Create both valid candidate paths for the module:

   touch src/responses.rs
   mkdir -p src/responses
   touch src/responses/mod.rs
   

4. Run rustfmt in check mode:

   cargo fmt --all -- --check
   

5. Observe the Error writing files prefix and exit status 1.

Meta

The behavior was reproduced with the stable version:

rustfmt --version:

rustfmt 1.9.0-stable (8bab26f4f6 2026-07-14)

It was also reproduced after cloning and building the current main branch of rust-lang/rustfmt:

repository commit: cd670efa2051459d8a4b0cab741c486746cda95a
rustfmt 1.10.0-nightly (cd670efa20 2026-07-21)
rustc 1.99.0-nightly (eff8269f7 2026-07-18)
cargo 1.99.0-nightly (3efb1f477 2026-07-17)

Environment:

Operating system: Linux, x86_64
Distribution: Ubuntu 24.04.4 LTS

Reproduce the issue with the listed cargo fmt --all -- --check steps and inspect rustfmt's check-mode error reporting and module-resolution handling. The fix is complete when the diagnostic no longer says "Error writing files" in check mode, still identifies the resolution error, and exits with status 1 without changing source files.