https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
Bug ID: 84889
Summary: Ideas on revamping how we format diagnostics
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: other
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Rust's compiler has some interesting ideas for printing diagnostics, which I
want to look at for gcc 9
Quoting an example from:
https://stackoverflow.com/questions/44003622/implementing-trait-for-fnsomething-in-rust
(hopefully not too badly mangled by bugzilla)
BEGIN QUOTE:
error[E0271]: type mismatch resolving `for<'r> <[closure@<anon>:30:27: 32:10]
as std::ops::FnOnce<(&'r i32,)>>::Output == ()`
--> <anon>:30:26
|
30 | run_the_runnable(&|x| {
| __________________________^ starting here...
31 | | println!("Hello from run(&i32) closure {}", x);
32 | | }, &x);
| |_________^ ...ending here: expected bound lifetime parameter , found
concrete lifetime
|
= note: concrete lifetime that was found is lifetime '_#63r
= note: required because of the requirements on the impl of `Runnable` for
`[closure@<anon>:30:27: 32:10]`
= note: required for the cast to the object type `Runnable`
error[E0281]: type mismatch: the type `[closure@<anon>:30:27: 32:10]`
implements the trait `std::ops::Fn<(_,)>`, but the trait `for<'r>
std::ops::Fn<(&'r i32,)>` is required (expected concrete lifetime, found bound
lifetime parameter )
--> <anon>:30:26
|
30 | run_the_runnable(&|x| {
| __________________________^ starting here...
31 | | println!("Hello from run(&i32) closure {}", x);
32 | | }, &x);
| |_________^ ...ending here
|
= note: required because of the requirements on the impl of `Runnable` for
`[closure@<anon>:30:27: 32:10]`
= note: required for the cast to the object type `Runnable`
END QUOTE
Things I like about this:
* line numbers within the quoted source code, which:
(a) make it easier to determine what is the quoted code,
and what is a message from the compiler
(b) make it easier to find the code in question
* the diagnostic and the followup notes are grouped, so it's easier to pick out
what messages relate to what
* there's a trailing blank line, after each diagnostic+notes group, helping the
above, and breaking up the "wall of text" effect
* ASCII art showing the interactions between two pieces of code
IIRC, clang does something where the left-hand column is only non-empty for the
start of a diagnostic; followup lines (e.g. due to line wrapping) are indented
by 1 char, so that the "wall of text" is broken up somewhat
We might want to revisit our current colorization choices.
Naturally if we make any major changes to how we output diagnostics we'd want a
compatibility option for people using IDEs that expect the existing format
How the above might interact e.g. with printing header file inclusion chains
etc etc would need to be thought through.
