cargo fmt does not do anything in tokio repo

[Diggsey]

I found this problem locally and wondered how tokio was checking formatting in CI.

As you can see they are calling rustfmt directly:
https://github.com/tokio-rs/tokio/blob/master/ci/azure-rustfmt.yml#L17

This comment links to a cargo issue:
rust-lang/cargo#7732

However, this cargo issue is closed and it's not clear how it's related.

[calebcartwright]

I can't really speak to the tokio nor cargo aspects, so you'd have to check in those respective repos for more details.

cargo fmt is a wrapper around the rustfmt binary to make it easier to run rustfmt across entire projects/workspaces. cargo fmt leverages the cargo_metadata crate which at a high level executes the cargo metadata --format-version 1 ... commands and deserializes the results. cargo fmt then uses the contents of that cargo metadata to structure and issue the corresponding rustfmt commands.

If, for whatever reason, the cargo metadata cannot be determined within the tokio workspace then that would be problematic for cargo fmt.

You could try running cargo fmt with the --verbose flag to get additional output, including the rustfmt commands it would issue. However, I don't get the sense the tokio challenges are related to rustfmt, though please let us know if there does turn out to be an issue on the rustfmt side.

[calebcartwright]

It looks like cargo fmt only finds files called lib.rs, main.rs and build.rs. Seen on both nightly and stable.

That is by design. cargo fmt will pass the main entry point file for each target for each package within the workspace. rustfmt then formats those recursively following the tree of imported mods, including those defined in separate files.

[topecongiro]

Outside of the linked issue, tokio uses macros to define modules, which rustfmt cannot recognize (https://github.com/tokio-rs/tokio/blob/67c4cc03919a58076c139f0930f28c3c41dad1e5/tokio/src/lib.rs#L326-L348).

I don't think that just adding support for modules defined inside macro calls fixes the issue in tokio crate, though we should add it anyway.

[ytmimi]

Somewhat related to #4034 since it's another case where we don't perform module resolution because of macros.