Hangs if procedural macro prints output when stdout is closed

[dtolnay]

Problem

Running cargo check | false (or more realistically cargo check | head) hangs if a macro prints more than a small number of lines to stdout.

Expected: same behavior as if the macro only prints a small number of lines to stdout, which is to not hang.

Steps

Cargo.toml

[package]
name = "repro"
version = "0.0.0"
edition = "2018"

[lib]
proc-macro = true

src/lib.rs

use proc_macro::TokenStream;

#[proc_macro]
pub fn repro(_input: TokenStream) -> TokenStream {
    // On my machine <202 lines terminates successfully.
    // >=202 lines hangs.
    for i in 0..1000 {
        println!("{}", i);
    }
    TokenStream::new()
}

src/main.rs

repro::repro!();

fn main() {}

Notes

• Tested with current master branch of cargo (13bded9) and nightly rustc 1.45.0-nightly (a74d1862d 2020-05-14) on linux. /path/to/cargo/target/release/cargo check | head

• Mentioning @ehuss because Ignore broken console output in some situations. #8236 looks relevant.

• Nightly cargo panicks and hangs, so this is not a regression from Ignore broken console output in some situations. #8236 which does eliminate the panic.

• I think the hang is cargo not rustc but I can't be sure. Reasoning: I ran cargo check --verbose to grab the last rustc invocation before the hang, and ran that rustc invocation piped to head, and that did not hang.

[ehuss]

Thanks for the high-quality report!

This is an unexpected consequence of #7838. Essentially there is a bounded message queue (to prevent buffering huge amounts of output in memory), but the loop that drains it is exiting when it shouldn't. Unfortunately I don't think there is a trivial fix. I'm thinking all the uses of ? need to be removed from the main loop. That's probably not too hard to do, but will need to investigate all the myriad of error cases. It should also probably handle if there is more than one error, and if that error is due to a closed stdout, only report that once.

I'll try to take a look at this soon.