cargo directly piping rustc output generates confusion with --explain

[huonw]

fn foo() {
    match () {
        () => {}
        _ => {}
    }
}

cargo build
   Compiling error-explain v0.1.0 (file:///home/huon/projects/test-rust/error-explain)
src/lib.rs:4:9: 4:10 error: unreachable pattern [E0001]
src/lib.rs:4         _ => {}
                     ^
src/lib.rs:4:9: 4:10 help: pass `--explain E0001` to see a detailed explanation
error: aborting due to previous error
Could not compile `error-explain`.

To learn more, run the command again with --verbose.

The error message looks a lot like cargo build --explain ... should work, but it's really rustc telling the user to pass that flag to rustc, and cargo is just dumping rustc's output straight out.

[alexcrichton]

In the past we had lots of problems if we didn't just blindly pipe the output of the compiler back to the user, so I'm not sure how much Cargo itself can do here other than add an --explain flag which recommends running the compiler instead.

[huonw]

Anything that avoids the confusion. :)

What if cargo ... --explain ran the compiler with --explain?

[alexcrichton]

I'd probably prefer to just change the wording to say something like "Run rustc --explain" as otherwise we'd have to add --explain to a whole lot of subcommands (test, run, bench, build, ...)

[caspark]

"Run rustc --explain E0001" would have been sufficient to avoid my confusion ( @huonw raised this on my behalf).

More generally though, this was just one case of a newbie - i.e. me, or perhaps I'm just passing the newbie stage, since I didn't actually need the extended explanation! I was just curious what it said - being tripped up by Cargo & (what I see as) the rest of Rust not playing nicely together as I expect.

Another example is cargo test -- --nocapture, where to me it would make more sense to be instructing Cargo to not swallow the output (even though I gather (?) the args are going to the test executable, so it kind of makes sense).

More succinctly, it's my expectation that I never need to know about rustc or its intricacies when using cargo. Now, maybe you aren't intending to meet that expectation. However, I can't remember the last time I had to interact with javac or scalac directly (or worry about their specifics) rather than expressing my intent to Maven/Gradle/SBT. Hence, I expect others from a similar background would have similar expectations.

[alexcrichton]

@caspark the --nocapture example at least is something where Cargo itself understands nothing about the option, but the underlying binary being run (the test harness) is the one that understands the --nocapture option. The extra -- tells Cargo that the following flags should all be passed down blindly to the the binary.

More succinctly, it's my expectation that I never need to know about rustc or its intricacies when using cargo.

Aha interesting! I had never really thought about it this way, and I suspect that's probably because I'm a little biased! This is definitely an interesting perspective to take, though, and something to keep in mind.

[huonw]

@alexcrichton I think the point about --nocapture is that it feels awkward: from the outside, cargo test is an abstraction around the details of test runners, and this breaks that abstraction, forcing users to understand how they work (and their flags) too.

(That is, someone using only cargo and no rustc finds it disconcerting that cargo understands nothing.)

[caspark]

Yep - what @huonw said about --nocapture is what I was trying to say.