Problem

Before -Zbuild-analysis, if people wanted to analyze cargo build information, they usually invoked Cargo with --message-format=json, captured stdout, and did live or post analysis.

Now with -Zbuild-analysis, the new structured logging system, Cargo has two similar systems emitting build information. While at the moment --message-format=json is closer to the actual compiler invocation, there are still overlaps between them. We plan to design around either unifying them, or having a clear principle for what message goes where. There was #16418, which did a dumb, simple pull request that redirected logs as stdout messages, and vice versa, without thinking more deeply about that question. The pull request was just speculation, and we didn't know if it was really useful, hence it was closed.

However, on Zulip one user pointed out that the removal of --timings=json without any alternative makes real-time timings analysis harder. There is no programmatic way to connect the build you just ran with a log file in ~/.cargo/log.

While the design space of log/message unification is much larger than this problem, we may want to provide a short-term solution that also gives us a better foundation to solicit feedback for different use cases

Proposed Solution

For a short term workaround to unblock people to do more experiments, we might want to

• either emit LogMessage::BuildStarted as a JSON message,
• or we add a new build-started JSON message with the run ID.

Either way, that enables user to associate them.

Note that everything should behind -Zbuild-analysis. If the nightly flag is not enabled, Cargo must not emit any new fields.

Notes

No response