Skip to content

Hangs if procedural macro prints output when stdout is closed #8245

Closed

Description

@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.

Activity

  1. ehuss commented on May 15, 2020

    @ehuss
    Contributor

    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.

  2. self-assigned this
    on May 15, 2020
  3. added a commit that references this issue on May 18, 2020
    b781ec4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-console-outputArea: Terminal output, colors, progress bar, etc.C-bugCategory: bugP-highPriority: Highregression-from-stable-to-betaRegression in beta that previously worked in stable.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions