rustc: errors should not display runtime boilerplate logging

[erickt]

Whenever I have a filename typo when running rustc, I always think I'm tripping over some compiler bug before I notice the error: error opening ... line at the top. Could rustc catch that the file doesn't exist earlier and cleanly exit instead?

% rustc does-not-exist.rs
error: error opening does-not-exist.rs
rust: upcall fail 'explicit failure', ../src/comp/syntax/parse/parser.rs:64
rust: domain main @0x10202d200 root task failed

[brson]

It would be nice if we got rid of that boilerplate for all failures (at least in rustc). We can have main immediately spawn a child task and catch the failure.

[brson]

My suggestion above will not actually fix the problem.

[brson]

Maybe as a temporary solution we can just add a secret runtime flag to turn these two log messages off

[brson]

Maybe we can just turn logging off by default for rustc

[graydon]

I'm going with a runtime library function to unsupervise on the trapped-and-reported error paths. Unsupervising the root task can mean "inhibit default runtime failure reporting" (though, er, probably should still exit 1?)

[brson]

My latest thought was to add core::logging::console_off()/console_on() that rustc could use, and which would be overridden by RUST_LOG.

[brson]

Some conversation from IRC:

    graydon there's a runtime call called "unsupervise", yes?
    brson   yes
    graydon what happens if we unsupervise the root?
    -->|    nettok ([email protected]) has joined #rust
    brson   I think the process ends successfully, though I don't know that we have tests for that
    graydon ok. what happens if you join an unsupervised task that has crashed?
    graydon failed I mean
    graydon I'm trying to tease apart the semantics
    brson   you get a message saying that it failed
    -->|    nmatsakis ([email protected]) has joined #rust
    graydon we want the runtime to exit(1) but we don't want it to panic and say "oh no, surprise failure!"
    graydon but we *do* want it to say "oh no, surprise failure" when there's an unexpected (otherwise-unreported) failure
    graydon so I'm suggesting that session::error(...) does { stderr.write(formatted error); rt::unsupervise(); fail; }
    graydon and the runtime sees the root failing, in an unsupervised state, and says "well, unsupervised means I don't panic about the error, but since it failed and it's the root I'll exit(1) because it really did not succeed and it'd be a bit superficial of me to call a failing root task exit(0)-status"
    graydon clearer?
    graydon (plausible?)
    |<--    kevina has left moznet (Quit: Leaving.)
    brson   Yes, it's clear. It's strange to me that unsupervise has special meaning to the root task, where failure still propagates, but doesn't log anything.
    brson   what if there are other tasks running still when the unsupervised root task fails?
    brson   what if some random unsupervised task has become the root task (because the root task died) and it's failure causes the process to die?
    graydon good questions, all
    graydon I don't know
    graydon another possibility is to have a set_exit_status(...) call?
    graydon or an rt wrapper that permits calling exit(int) and unwinds properly anyways?
    graydon (assuming we *should* unwind-on-exit? that itself is an interesting question; maybe not?)
    brson   oh yeah. we can just call sys::exit and kablooey everything
    brson   that seems reasonable for rustc
    brson   (not unwinding)
    graydon maybe
    graydon I mean, a destructor is a destructor
    graydon if there's a file handle open, I dunno, some OSs complain
    graydon I don't remember if any dtors run in C++. maybe just the global statics.
    brson   I'm going to add sys::set_exit_status and just make it set some global value in the kernel

[brson]

Here's what I'm thinking now:

• task::unsupervise will lower the log level of the failure message to 'info' from 'error'
• sys::set_exit_status will set the global process exit code, assuming that all tasks exit successfully. if a task supervised by a scheduler fails the process will still exit with the default failure code.

[brson]

0616cba adds sys::set_exit_status

[brson]

After further consideration I don't think having task::unsupervise change the log level of the failure message is right. The thinking is that calling unsupervise indicates that you're expected failure, which makes sense. But it could be that you have a hierarchy of tasks, with only the root of that heirarchy being unsupervised. In that case, you still might expect the children to fail, because you're counting on their parent being unsupervised, in which case we would still see a bunch of log messages.

[brson]

6c05214 makes rustc not display any logs unless RUST_LOG is present. I still plan to do a bit more to make sure it's foolproof, e.g. if some bug results in fail without going through the error reporting path rustc shouldn't just terminate silently.

[brson]

e36ea8e runs the compilation in a subtask and adds a hook into the error codepath that validates that any failure is properly reported. If the compilation fails without emitting an error diagnostic it displays an ICE.