OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Auto merge of #45019 - aidanhs:aphs-no-trans-worker-panic, r=alexcrichton

Browse Source 
Don't unwrap work item results as the panic trace is useless

Fixes #43402 now there's no multithreaded panic printouts

Also update a comment

--------

Likely regressed in #43506, where the code was changed to panic in worker threads on error.

Unwrapping gives zero extra information since the stack trace is so short, so we may as well just surface that there was an error and exit the thread properly. Because there are then no multithreaded printouts, I think it should mean the output of the test for #26199 is deterministic and not interleaved (thanks to @philipc https://github.com/rust-lang/rust/issues/43402#issuecomment-333835271 for a hint).

Sadly the output is now:
```
thread '<unnamed>' panicked at 'aborting due to worker thread panic', src/librustc_trans/back/write.rs:1643:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: could not write output to : No such file or directory

error: aborting due to previous error
```
but it's an improvement over the multi-panic situation before.

r? @alexcrichton
This commit is contained in:
bors 2017-10-05 10:50:11 +00:00
commit abef7e1fd2
1 changed files with 6 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
src/librustc_trans/back/write.rs
View File

@ -1636,9 +1636,9 @@ fn start_executing_work(tcx: TyCtxt,
needs_lto.push(result);
}
Message::Done { result: Err(()), worker_id: _ } => {
shared_emitter.fatal("aborting due to worker thread panic");
shared_emitter.fatal("aborting due to worker thread failure");
// Exit the coordinator thread
panic!("aborting due to worker thread panic")
panic!("aborting due to worker thread failure")
}
Message::TranslateItem => {
bug!("the coordinator should not receive translation requests")
@ -1739,23 +1739,16 @@ fn spawn_work(cgcx: CodegenContext, work: WorkItem) {
// Execute the work itself, and if it finishes successfully then flag
// ourselves as a success as well.
//
// Note that we ignore the result coming out of `execute_work_item`
// which will tell us if the worker failed with a `FatalError`. If that
// has happened, however, then a diagnostic was sent off to the main
// thread, along with an `AbortIfErrors` message. In that case the main
// thread is already exiting anyway most likely.
//
// In any case, there's no need for us to take further action here, so
// we just ignore the result and then send off our message saying that
// we're done, which if `execute_work_item` failed is unlikely to be
// seen by the main thread, but hey we might as well try anyway.
// Note that we ignore any `FatalError` coming out of `execute_work_item`,
// as a diagnostic was already sent off to the main thread - just
// surface that there was an error in this worker.
bomb.result = {
let _timing_guard = cgcx.time_graph.as_ref().map(|tg| {
tg.start(time_graph::TimelineId(cgcx.worker),
LLVM_WORK_PACKAGE_KIND,
&work.name())
});
Some(execute_work_item(&cgcx, work).unwrap())
execute_work_item(&cgcx, work).ok()
};
});
}