In some cases rustfmt emits nothing on files with `#![cfg_attr(rustfmt, rustfmt_skip)]` when using `--emit=stdout`

[mchernyavsky]

trafficstars

Environment

• Rust toolchain version: 1.64.0-nightly (d5e7f4782 2022-07-16) x86_64-apple-darwin
• Operating system: macOS 12.5.1
• Rustfmt version: rustfmt 1.5.1-nightly (d5e7f478 2022-07-16)

Problem description

The original issue in IntelliJ Rust tracker - https://github.com/intellij-rust/intellij-rust/issues/8913

I'm not sure if it's a bug or not, but I expected that rustfmt just prints the file's content without changes.

Steps to reproduce

1. Clone https://github.com/subspace/subspace
2. Checkout commit 93bfaa3f8ebe2973c4939e6be21caffff9e57933
3. rustfmt --emit=stdout < ./orml/vesting/src/weights.rs
4. Observe the output is empty

If you remove #![cfg_attr(rustfmt, rustfmt_skip)] line from weights.rs everything work as expected.

At the same time, if I just put #![cfg_attr(rustfmt, rustfmt_skip)] to the simple "Hello, World" file:

#![cfg_attr(rustfmt, rustfmt_skip)]

fn main() {
                println!("Hello, World!")
}

and run rustfmt:

rustfmt --emit=stdout < ./src/main.rs

rustfmt would print the file content without changes.

[ytmimi]

Thanks for the report!

Confirming I can reproduce this using the current master.

[calebcartwright]

I'm actually unable to reproduce this when using more recent versions of rustfmt. At 93bfaa3f8ebe2973c4939e6be21caffff9e57933 your repository was pinned to the nightly-2022-05-16 toolchain which had rustfmt version rustfmt 1.4.38-nightly (42e1761 2022-05-15)

That version predates the bugfix from #5369 and so the ability to reproduce the bug in the older version of rustfmt would not be unexpected.

Perhaps I'm missing something though, are either/both of you certain you're able to reproduce the scenario using a newer version of rustfmt than the one pinned at that commit?

[ytmimi]

@calebcartwright using the current master 38659ec6ad5f341cf8eb3139725bf695872c6de7

Here are some steps you can take to reproduce:

1. Confirm the commit hash: git log -1 --pretty=format:"%h". I get 38659ec6
2. write the issue snippet to a file named issue_5519.rs:

#![cfg_attr(rustfmt, rustfmt_skip)]

fn main() {
                println!("Hello, World!")
}

3. run rustfmt from stdin: cargo run --bin rustfmt -- --emit=stdout <paste-snippet> You'll notice that we emit the original snippet back out.
4. run rustfmt from a file cargo run --bin rustfmt -- --emit=stdout issue_5519.rs. You'll notice that nothing is emitted.

[ytmimi]

I believe the issue can be tracked down to the call to filter() when constructing the files iterator. We skip the file while constructing the iterator so we never actually do anything with it.

https://github.com/rust-lang/rustfmt/blob/38659ec6ad5f341cf8eb3139725bf695872c6de7/src/formatting.rs#L141-L144

I think I've got a fix for this

[calebcartwright]

run rustfmt from a file cargo run --bin rustfmt -- --emit=stdout issue_5519.rs. You'll notice that nothing is emitted.

I'm not sure I follow you. The original report is about stdin (with redirection, but still stdin) to stdout, whereas you're talking about a file based input with stdout output.

I'd want to double check to confirm, but I think the separate scenario with file to stdout being empty when there are no formatting changes to be made (regardless of whether that's due to the file being skipped or already formatted) is actually intentional behavior.

[ytmimi]

Ahh okay I see. I actually can't reproduce the issue as stated in the description. rustfmt --emit=stdout < issue_5519.rs works just fine with the latest master https://github.com/rust-lang/rustfmt/commit/38659ec6ad5f341cf8eb3139725bf695872c6de7. I got too hung up on the different behaviors when running rustfmt with stdin vs on a file. Sorry about that.

[calebcartwright]

Closing as a functional duplicate of an older issue