Add more info to an ICE message

[nodakai]

The new message looks like

note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report:
note:   https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: version: 1.9.0-dev (3d7e519b7 2016-03-20)
note: run with `RUST_BACKTRACE=1` for a backtrace

Wonder if the version string should appear the first. Any suggestions?

[rust-highfive]

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

In theory if this is an internal assertion error we may want actually dump a whole bunch of information. For example we could dump things like:

• the entire output of --version --verbose
• all command line arguments
• a full backtrace by default

We may want to even go the extra mile and emit the information into a temporary file (e.g. bug-report.md) and ask that the file be directly uploaded to github (where the file may have more instructions).

I guess what I'm getting at is that this probably isn't too helpful for readers of the message except during bug reports, and we could perhaps add a whole lot more contextual information to bug reports by default as well (without streaming it all to the console).

cc @rust-lang/compiler
cc @rust-lang/tools

[bors]

☔ The latest upstream changes (presumably #32369) made this pull request unmergeable. Please resolve the merge conflicts.

[nodakai]

My impression was we don't suffer from a lack of information in a bug report that often. Instead I tend to see we cry for "Minimal case! Minimal reproducible test case!". So I'm not sure if a support for a rich crash report really helps the project.

By the way, as someone who gets paid by working for a proprietary software project, I'm not very comfortable with pastebin-like services.

the entire output of --version --verbose

Actually the "verbose" mode essentially adds the host triple only... Anyways this is straightforward.

all command line arguments

Minimal change to rustc_driver::run() will suffice

a full backtrace by default

What prevents us from hardcoding a full backtrace? Performance hit?

I think we can improve rustc_driver::monitor() so that if the passed closure panics, it's re-run with RUST_BACKTRACE=1. How do you like this idea?

[eddyb]

What prevents us from hardcoding a full backtrace? Performance hit?

No, in the general case it's risking bugs in the libbacktrace code that may not be avoidable (other than by having RUST_BACKTRACE=0).
For rustc I think it's safe to have it enabled for ICEs, but not other fatal errors, maybe with a way to turn it off.
Problem is, the "abort if any errors have occurred mechanism uses a panic so every compilation with errors would have an unnecessary backtrace if nothing is changed.

[alexcrichton]

Yeah it's certainly slow to produce a backtrace, but that doesn't matter much as we're just doing it whenever an error is generated.

I wouldn't recommend re-running the closure to the monitor function, errors like this can be transient sometimes or take a very long time to produce (long compiles), so we'd want to collect as much information as possible from when it happens originally.

[nrc]

I would be wary about dumping a tonne of info for an ICE by default. As a user experience, hitting an ICE is bad enough already, we really shouldn't make it worse by flooding the console with info. The majority of users are passive and will not report the bug, they are just quietly annoyed by it and dumping more info (esp. a backtrace) will just make them more annoyed. If we do this (and it seems like a good idea) we could perhaps do it by default on nightly and with a flag or env var on other channels (changing the "run with RUST_BACKTRACE=1 for a backtrace" message to something like "run with --verbose-ice for more information".

On this actual PR, I don't feel strongly either way.

[nodakai]

The new ICE message will look like

$ rustc -O /tmp/nodakai/ice.rs
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report:
note:   https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: version: 1.9.0-dev (1437edb98 2016-03-22)
note: host: x86_64-unknown-linux-gnu
note: arguments: ["rustc", "-O", "/tmp/nodakai/ice.rs"]
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'impossible range in AST', src/librustc_front/lowering.rs:1292
note: Run with `RUST_BACKTRACE=1` for a backtrace.

This patch adds version, host and arguments fields. I'll address the backtrace issue in a separate commit.

[alexcrichton]

The tools team discussed this during triage yesterday, and the conclusion was that we like the idea here but probably want to tweak it. The key point we realized is that we don't want to pollute the ICE message on the console more than it is already today, but we probably want to perhaps dump more information somewhere. Along those lines, we envisioned something like:

1. When an ICE is encountered, the compiler will dump all contextual information to a "bug report file". This file is likely just bug-report-XXXXX.md or something like that, and it's essentially something that can be copy/pasted into an issue report.
2. The ICE message is tweaked slightly to indicate where the bug report is located on disk (probably in --out-dir).
3. The ICE message already points to CONTRIBUTING.md, so we can tweak the wording there to indicate that if you're there because of an ICE you should copy/paste that markdown file into an issue and submit it. This file would also warn you to double-check the contents of the file to ensure you're not leaking any information you don't want (sensitive path names, etc).

That should help give us more information "by default" without polluting the terminal, and it's also an nice expandable vector for adding more information in the future.

How's that sound @nodakai?

[nodakai]

Sounds good, I'll work on a new patch.

Let me take this opportunity to fix this discouragingly lengthy URL
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

At least it should be https://www.rust-lang.org/contribute.html and ideally just rust-lang.org/contribute.html . Is redirection guaranteed here?

[bors]

☔ The latest upstream changes (presumably #32773) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Closing due to inactivity, but feel free to resubmit with a rebase!