The format itself allows children to have children of their own, so technically someone parsing the format needs to allow for that case, even though rustc never produces it. Maybe the format should make that clear by separating out a Child type with fewer fields.
So this is roughly the format that I would like to see. I can’t see to copy-and-paste here so this is a link to a gist. But the high-level idea is to include roughly the same logical information that we include today, along with presentation information. The presentation information would be literally the same output that rustc emits, but augmented with formatting info (like "this should be styled as the “main message”, or “this is the filename/line-number” or “this is a line from the source text”). The goal of the presentation information is to make it easy for tools to reproduce rustc’s output and formatting, which will presumably evolve and improve, without having to reproduce all of our internal logic for extracting snippets and rendering annotations.
I see two problems with RUSTFLAGS to convey a request for JSON:
rustc itself doesn't respect it, only cargo (we could change this)
I see RUSTFLAGS as being more for humans to inject flags than tools, but I guess that's a relatively minor point; specifically, I expect people to do things like make foo RUSTFLAGS="-g" which would then ignore any RUSTFLAGS settings installed by the editor.
But this will depend a lot on the environment. I am assuming a tool like emacs, where users may wish to specify their own build command, but we would like to silently control the output format. But this particular aspect of the discussion (how to select json output) feels like it belongs more to the original thread
There are also errors due to deny'd lints, these don't have an error code, but they have a lint name. Clippy goes as far as giving a url to the lint documentation, but the explanation is probably enough.
I don't think so, the logical format is great to process, and I'm not creating the tooltip, I'm utilizing an existing framework.
I'm not sure I follow. Currently, though, we produce a suggested edit. I guess you are saying what if we made multiple suggested edits?
Yeah, it'd be good to expose the lint name in the JSON I imagine.
Seems fine. I figured that the more "inline" the presentation, the less useful rustc's output would be. I could imagine though that you might want to explain borrow check errors this way (for example) -- but maybe not. Maybe you can render it inline.
It hasn’t been merged yet, but to get the same behaviour, you can install the build package (version 0.63.0), install the linter package (search for linter base) and create an .atom-build.js in your project root with the following content:
Adding the .atom-build.js file from within atom might require an atom restart (Ctrl + Alt + R).
Then you should be able to press Ctrl + Alt + B to trigger a build. The exact keys may vary between operating systems (F6 seems to work, too).
remove the suggested_replacement field, and instead add a new "error level".
generally use suggestions more often. E.g. in unresolved name errors
the label field
I've so far ignored it. Many errors do not set it, and with those that do set it, I've found that I can't replace the main message, and that it's partially redundant with the notes. An example is a type-mismatch. let _: () = 5; gives "type mismatch" for the message, expected type '()' and got type '_' for the notes, and then "expected (), found integral variable" for the label. The label is nicer than the notes, but still needs the message.
I could simply show it when it's there, but I don't want to clutter the error popups with redundancy.
I'm not sure how to improve on this yet. An alternative would be to repeat the error at every expansion location. Or just show something at the location of the expansion.