Update --timings=json output include data similar to the HTML output

[CraZySacX]

Content

This PR attempts to bring the JSON output when using the --timings=json flag more inline with the data that is output when requesting HTML.

• Added custom Serialization impls to the Timings, and Unit structs.
• Added a report_json function to output the data in a manner similar to the HTML output.
• Removed the output of the timing reports on stdout during unit completion when the --timings=json flag was used. That information in now collected in the final report.

Testing

This was my method. There is probably a better way.

1. Built a release version of Cargo. cargo build --release
2. In a test project ran cargo clean && <path-to-cargo>/target/release/cargo build --timings=json -Z unstable-options
3. Verified that JSON output was generated in the <basedir>/target/cargo-timings/ folder.

[rust-highfive]

r? @alexcrichton

(rust-highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Thanks for the PR, but I'm going to be stepping down from the Cargo team so I'm going to un-assign myself from this. The Cargo team will help review this when they get a chance.

[CraZySacX]

r? @ehuss

[epage]

There are some things that raise some flags for me

• This moves away from serializing machine_message to internal data structures. Using code in machine_message helps raise awareness of the compatibility requirements when making changes and is more discoverable for people who want to parse the output
• Generally we print messages as we go rather than doing one bug final message
• The PR doesn't explain why some information was left out of the report for stablization

Overall, I'd recommend

• Find out the thought process for what data got stablized
• Create an issue for discussing stabilizing more information (Issues are much better for discussing requirements and design while PRs are much focusing on an implementation to resolve an Issue)
• Focus on incrementally printing machine_message structs.

[CraZySacX]

I can open an issue to discuss if you'd prefer, but I have a few question:

• The HTML reporting uses internal data structures exclusively. The intent here was to emulate the HTML reporting. Are you suggesting that all of the reporting structs move to machine_message?
• Capturing stdout output printed on the fly in a meaningful way is a bit cumbersome. Again, emulating the HTML reporting was a goal, so the larger final output at the end was used. Should we do both?
• Forgot to mention that the data collected was mostly inline with that the HTML report collected. It does appear I missed a couple fields. Those should definitely be included.

[epage]

Capturing stdout output printed on the fly in a meaningful way is a bit cumbersome. Again, emulating the HTML reporting was a goal, so the larger final output at the end was used. Should we do both?

Pretty much all cargo messages (except cargo metadata) communicate like this. libtet also works this way with providing suite summary messages in addition to the individual tests.

The HTML reporting uses internal data structures exclusively. The intent here was to emulate the HTML reporting. Are you suggesting that all of the reporting structs move to machine_message?

I can definitely understand this. I love the idea of a separating out the view and model like this. At times though, shortcuts are made because not everything is locked down yet. This is why I was recommending looking into and having a discussion on why not everything is exposed.

[ehuss]

Closing as we unfortunately don't have the capacity to accept new features of this kind at this time. Before opening a PR, please open an issue to discuss possible design choices. Just skimming this, it seems to expose internal details like Unit that I think we definitely don't want to expose at this time. I also think there are some fundamental questions about what this would be used for.