We’ve touched on the json format a couple of times here and here. There are some great discussions there, though in this particular thread I wanted to talk about where we need to go to stabilize the json format so that tools and editors can start relying on it.
Currently, that json format is still under a -Z unstable-options flag. Over a month ago, we switched the test suite to using the json as its main format, and its been happily chugging along. Seems like a good time to revisit making the json format stable.
Example error:
error[E0381]: use of possibly uninitialized variable: `x`
--> uninit.rs:15:9
|
15 | foo(x);
| ^ use of possibly uninitialized `x`
error: aborting due to previous error
Same error, in json:
{"message":"use of possibly uninitialized variable: `x`","code":{"code":"E0381","explanation":"\nIt is not allowed to
use or capture an uninitialized variable. For example:\n\n```compile_fail\nfn main() {\n let x: i32;\n let y = x;
// error, use of possibly uninitialized variable\n}\n```\n\nTo fix this, ensure that any declared variables are
initialized before being\nused. Example:\n\n```\nfn main() {\n let x: i32 = 0;\n let y = x; // ok!\n}\n```\n"},
"level":"error","spans":[{"file_name":"uninit.rs","byte_start":546,"byte_end":547,"line_start":15,"line_end":15,
"column_start":9,"column_end":10,"is_primary":true,"text":[{"text":"foo(x);","highlight_start":9,"highlight_end":10}],
"label":"use of possibly uninitialized `x`","suggested_replacement":null,"expansion":null}],"children":[],"rendered":
null}
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":null}
Features of the json format
The json compiler message format is built on:
- “message”: The compiler message text
- “code”: The corresponding error code, if one, and associated code explanation, if any
- “level”: The level of the message (error, warning, note, help, etc.)
- “spans”: The areas we are going to be highlighting in any associated source. The primary span is the main span associated with the error message. Additionally, labeled spans will call out points of interest in an associated source snippet.
- “children”: Any associated submessages. Eg) A deprecated warning may carry with it supplemental notes about how long the feature will be supported before it’s removed.
- “rendered”: The rendered results of a suggestion
You can see the full structs here: https://github.com/rust-lang/rust/blob/master/src/libsyntax/json.rs#L74-L146
One json message is emitted per compiler message.
There has been some discussion on adding the rendered full message to the json. We can support this using an additional field for the full rendered error (or perhaps two fields, one for styled text and one for simple text).
For tools/editors authors - are there fields you are missing from the above set (assuming the full rendered messages are included)?
