Currently the FailureNote diagnostic level serializes to the empty string. This results in JSON messages containing level: "", which I'm not sure how to interpret.
This was added in #48684, though reading that PR I can't really figure out why it was added and how it relates to compiletest changes.
An easy way to see this is to trigger a diagnostic that prints "For more information…", for example:
// E0005
let Some(_y) = Some(1);
will emit a JSON value like this:
{
"message": "For more information about this error, try `rustc --explain E0005`.",
"code": null,
"level": "",
"spans": [],
"children": [],
"rendered": "For more information about this error, try `rustc --explain E0005`.\n"
}The empty string is not very descriptive of how to handle the message. I would suggest having it serialize to something more deliberate, such as "failure-note". I can't really tell what the intent of FailureNote is, so it's hard to say what it should be.
cc @GuillaumeGomez who might know more.
Currently the
FailureNotediagnostic level serializes to the empty string. This results in JSON messages containinglevel: "", which I'm not sure how to interpret.This was added in #48684, though reading that PR I can't really figure out why it was added and how it relates to compiletest changes.
An easy way to see this is to trigger a diagnostic that prints "For more information…", for example:
will emit a JSON value like this:
{ "message": "For more information about this error, try `rustc --explain E0005`.", "code": null, "level": "", "spans": [], "children": [], "rendered": "For more information about this error, try `rustc --explain E0005`.\n" }The empty string is not very descriptive of how to handle the message. I would suggest having it serialize to something more deliberate, such as "failure-note". I can't really tell what the intent of
FailureNoteis, so it's hard to say what it should be.cc @GuillaumeGomez who might know more.