Add message-format=json support, second take

[konstin]

This is #53 with the merge conflicts resolved and the review comments addressed. I also copied DiagnosticLevel from @epage.

CC @roblabla

[konstin]

There's one clippy warning but I'm not sure what to do about that since the memory layout of that enum should not be an issue at all.

warning: large size difference between variants
  --> src/messages.rs:86:5
   |
86 |     CompilerMessage(FromCompiler),
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(clippy::large_enum_variant)] on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
help: consider boxing the large fields to reduce the total size of the enum
   |
86 |     CompilerMessage(Box<FromCompiler>),
   |                     ^^^^^^^^^^^^^^^^^

[roblabla]

Thanks for doing this. I've been meaning to do it but haven't been able to find the time 😓 .

The vast majority of messages from cargo will be of the FromCompiler, so I don't think forcing one more allocation in that path is a good idea, especially when the gains are fairly trivial. I feel like the warning should be ignored in this case.

[ehuss]

Just some minor documentation notes.

[ehuss]

Maybe add a note that this may be empty? Some messages don't have a span (like "main not found"), and child messages sometimes don't have spans when they are attached to their parent.

[konstin]

I think it's clear that that Vec can be empty

[ehuss]

This changed in 1.23. Before 1.23 it was used by suggested replacements.

[konstin]

Can we just assume that everyone uses a reasonably recent compiler version?

[konstin]

Thanks for the review @ehuss, I've fixed most doc strings now.

[oli-obk]

The cargo team would like to have the cargo_diagnostics crate under their organization. I think it's fine to start out in a private repo and let them fork or move it

[oli-obk]

Can you put these types into their own crate so we can reuse them from the compiler and from rustfix? (maybe rustc_diagnostics)

[oli-obk]

It would make sense to share these types with cargo. cc #63

We could have a dep graph like

where each crate reexports its dependencies

[konstin]

I'd love to have a base crate shared with cargo. Imo we should track that in one central issue so information doesn't get lost across thread, maybe directly in the cargo repo.

Personally, I'd like to have some kind of cargo_shared_types crate that contains types for all the json cargo emits, which is currently diagnostics, cargo metadata and the build plan. But for now I'd like to have this merged and released before doing bigger refactorings work because I'm already using this branch in pyo3-pack.

[oli-obk]

The cargo team would like to have the cargo_diagnostics crate under their organization. I think it's fine to start out in a private repo and let them fork or move it

Actually they just want it to be a subcrate of the cargo repo. Can you make a crate out of each of the two modules and add them to the cargo repo?

[oli-obk]

Personally, I'd like to have some kind of cargo_shared_types crate that contains types for all the json cargo emits, which is currently diagnostics

We should still split it in two as I suggested above, because other crates (e.g. rustc) won't need to know about the cargo_diagnostics, just about the rustc_diagnostics

But for now I'd like to have this merged and released before doing bigger refactorings work because I'm already using this branch in pyo3-pack.

I guess it won't even be a breaking change if we just make it pub use rustc_diagnostics as diagnostics; So seems ok to me