rustc: errors should not display runtime boilerplate logging

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

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.

My suggestion above will not actually fix the problem.

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

Maybe we can just turn logging off by default for rustc

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?)

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

Some conversation from IRC:

    graydon there's a runtime call called "unsupervise", yes?
    brson   yes
    graydon what happens if we unsupervise the root?
    -->|    nettok (quassel@D59D07A8.37B61F3F.59131532.IP) 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 (nmatsakis@E58334A4.A3E4B789.2321E71E.IP) 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

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.

0616cba adds sys::set_exit_status

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.

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.

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.

Implement llvm.fma.v* intrinsics

Bump CBMC to 5.62 and Viewer to 3.6 (rust-lang#1405)

Merge rust-lang#1405

Auto merge of rust-lang#1405 - RalfJung:stage-0, r=RalfJung

Navigation Menu

Repository navigation

rustc: errors should not display runtime boilerplate logging #1405

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

rustc: errors should not display runtime boilerplate logging #1405

Description

Activity

brson commented on Dec 31, 2011

brson commented on Jan 11, 2012

brson commented on Jan 11, 2012

brson commented on Jan 11, 2012

graydon commented on Jan 11, 2012

brson commented on Jan 11, 2012

brson commented on Jan 13, 2012

brson commented on Jan 13, 2012

brson commented on Jan 13, 2012

brson commented on Jan 13, 2012

brson commented on Jan 13, 2012

brson commented on Jan 14, 2012

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions