Add JSON output for errors

[Timmmm]

There is already an --emit json option that emits formatting changes as JSON. However if Rustfmt encounters a parse error it prints the error to stderr in human readable form and exits with error code 1.

$ rustfmt --emit json lib.rs
error: expected one of `!` or `::`, found `<eof>`
  --> /.../src/lib.rs:16:1
   |
16 | sdf
   | ^^^ expected one of `!` or `::`

failed to parse Real("/.../src/lib.rs")

It would be helpful in some situations to be able to have these errors in JSON format too. For example for IDE integration or CI. (One of my coworkers is using a horrible regex to parse this, against my advice!)

I think an --emit-errors json option would be reasonable.

• rustfmt version: rustfmt 2.0.0-rc.2-nightly (e91edf56 2020-08-04)
• From where did you install rustfmt?: Git master, from yesterday.

[calebcartwright]

Thank you for the suggestion @Timmmm. I had a similar thought no too long ago, although I was thinking that when the user specifies the json (or xml) emit mode, then that json output should include any errors/warnings along with any formatting changes.

Would something like that meet your use case? Or are you thinking you'd need divergent emit modes between errors/warnings and formatting, and if so, what are those use cases?

[Timmmm]

Yes that would work for us and it seems like a good solution. :-)

[whizsid]

I like to work on this issue. I will send a PR ASAP.

[whizsid]

@calebcartwright There are two places in the parser that emitting the outputs to stdout .

rustfmt/src/formatting/syntux/parser.rs

Line 69 in 22c4437

sess.emit_diagnostics(db);

rustfmt/src/formatting/syntux/parser.rs

Line 183 in 22c4437

db.emit();

I should remove these emit codes and add these Diagnostic information to ParserError. After that I should catch them in emitter. Is this approach correct? And I am implementing a new method in emitter named emit_operation_errors to output operation errors in JSON format.

[calebcartwright]

I should remove these emit codes and add these Diagnostic information to ParserError. After that I should catch them in emitter. Is this approach correct?

Thanks for looking at this one @whizsid! You bring up a good point here that I'd previously overlooked, but no I don't think that approach will be viable as described. rustfmt uses the rustc parser to generate the AST which is then used for formatting, and in the vast majority of cases of encountered parser errors the rustc parser will emit them directly. DB's in the rustc parser have to explicitly be cancelled or emitted (which in turns ensures it's cancelled) or else it will panic.

This starts to get deep into the weeds of the rustc parser pretty quickly, so I'd advise initially focusing on just the rustfmt error and emitter (so the rustfmt operation error in this case) and we can continue to brainstorm on if/how to best handle the rustc errors.

I suppose we could enhance the conditionals used construct the span handler for the parse session with a different rustc emitter based on the the rustfmt emit mode, as the parser does have a json emitter implementation, though the tricky part would likely be determining the destination value for the json emitter construction 🤔

I need to think on this one a bit