Add initial integration for --json=timings behing -Zsection-timings

[Kobzol]

What does this PR try to resolve?

This PR adds initial support into Cargo for JSON timing sections, implemented in rustc in rust-lang/rust#142123. This allows Cargo to read frontend/codegen/linking time from rustc, and thus reporting slightly more detailed data in the cargo build --timings output.

The PR modifies Cargo to tell rustc to emit the section messages (--json=...,timings), and it adds the section timings data to the HTML table output and the JSON output. It does not yet integration different sections in the HTML unit chart (I want to do that as a follow-up).

Note that the JSON timings are currently only supported on the nightly compiler (they are not stabilized). The new behavior is thus gated behing an unstable Cargo flag (-Zsection-timings). When the flag is unused, the HTML table should look more or less the same as before, just that the code now supports both options.

How to test and review this PR?

You can run e.g. this to generate the timing report with a nightly compiler:

export RUSTC=`rustup +nightly which rustc`
target/debug/cargo build -Zsection-timings --timings

on some crate, e.g. ripgrep.

Tracking issue: #15817

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Mind moving the rename into the commit that added it so this commit can be focused just on json output?

[epage]

Why was this marked as resolved? I'm not seeing it resolved as requested nor an explanation for why it shouldn't happen

[Kobzol]

Ok, so based on feedback I'm fine with moving this to a fully dynamic approach.

Before I do that though, do you have any suggestions on how to detect whether the timings flag should be passed to Cargo? Is there any precedent for doing something in Cargo only on the nightly channel, or more precisely only with nightly rustc? Or would you prefer that we add an unstable Cargo flag for this?

[epage]

Before I do that though, do you have any suggestions on how to detect whether the timings flag should be passed to Cargo? Is there any precedent for doing something in Cargo only on the nightly channel, or more precisely only with nightly rustc? Or would you prefer that we add an unstable Cargo flag for this?

We discussed this in today's cargo team meeting. We should not enable an unstable rustc feature implicitly but require an explicit opt-in.

• People using nightly for other functionality (e.g. miri or a sanitizer) shouldn't pick up unstable features they aren't using
• We'd want more than to assume that rustc outputs it in a compatible way / the flag exists and instead have feature detection which is difficult to get right.

[Kobzol]

Fair enough, I'll add an explicit feature flag then. It's true that if it was implicit, if the rustc format changes in the future, it could break nightly cargo users of cargo build --timings. That would be solvable if Cargo was a subtree, but with a submodule it would be quite difficult to ensure that both rustc and cargo change at once.

[Kobzol]

Ok, I rewrote the PR and updated the PR description. It is now gated behind an unstable -Zsection-timings flag, and it renders the sections into the HTML table in a fully dynamic manner.

[Kobzol]

Restructured the commits

[epage]

Thanks!