Tracking issue for --unit-graph

Implementation: https://github.com/rust-lang/cargo/pull/7977
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#unit-graph

Summary
The --unit-graph flag emits a JSON structure showing Cargo's internal unit graph.

Unresolved issues

• Is there a better way to expose this information? I think in many cases, to make this useful, you have to also run cargo metadata (to get package names, for example). It seems a little silly to have to run two commands. Adding this to cargo metadata I think will be hard from a UX standpoint. It would require a superset of all flags of all commands (for example, cargo check --profile=test fundamentally changes things, so it would need to reproduce that flag). Every time I look at that, it seems really messy. There's also some flags like --target that don't interact with cargo metadata very well.
  • The primary motivator is to get access to feature relationships. But maybe there is a better way to deal with that?
• Which parts of the output should be stabilized? This structure is very low-level, and thus inherently at high risk of changing in the future and being unstable. I think at a minimum we should document that it is not guaranteed to be backwards compatible. Should we filter some fields on stable?
• Can't differentiate a normal check and a check for a test. The serialize implementation for CompileMode does not output the different kinds. Not sure how this should be displayed.

Start by reading the linked implementation pull request and the unstable Cargo documentation for --unit-graph. Review the three unresolved questions about exposure, stabilization, and CompileMode output. The work is complete only when the desired behavior and output policy are decided and reflected in the implementation and documentation.