Skip to content

Conversation

@weihanglo
Copy link
Member

@weihanglo weihanglo commented Dec 19, 2025

What does this PR try to resolve?

Add output control for build analysis logs.
The motivation of this are:

  • User may want to pipe build log to stdout and process them in a stream manner in real time, rather than in a log file.
  • Output to stdout so we can have a replacement for the unstable --timings=json option.

See doc update for more: 3df1405.

Example config:

[build.analysis]
enabled = true
console = true
file = false

How to test and review this PR?

cargo run -- build -p rustfix -Zbuild-analysis --config build.analysis.enabled=true --config build.analysis.console=true --config 'build.build-dir="target/mytmp"' --message-format=json

Open questions:

  • Console output is only enabled when --message-format has a JSON option, so it won't interleave with status messages if people don't want JSON messages at all.

  • Logging is best-effort for now. If there is any broken pipe, no error or warning will show

  • Alternative schemas

    • A destination field
      [build.analysis]
      destination = ["file", "console"]
    • Remove build.analysis.enabled. Each output option enablement control whether log is generated
      [build.analysis]
      console = true
      file = true
    • No build.analysis.file. console and file output are mutually exclusive
      [build.analysis]
      write-to-console = true # No log file output

So this preserve whether the config value is actually set.
This is for upcoming logging-to-shell feature
Tests are prepared to show the change of output destination control
@weihanglo weihanglo added A-timings Area: timings Z-build-analysis Nightly: build-analysis labels Dec 19, 2025
@rustbot rustbot added A-documenting-cargo-itself Area: Cargo's documentation S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 19, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 19, 2025

r? @ehuss

rustbot has assigned @ehuss.
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

root_units.iter().map(|unit| unit_to_index[&unit]).collect();

for (index, unit) in units.into_iter().enumerate() {
logger.log_batch(units.into_iter().enumerate().map(|(index, unit)| {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not usually a fan of big map functions and tend to prefer explicit loops for them

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shell holds a mutex lock and stdout lock, which are a bit expensive to work with. Other alternatives are having a buffer for shell print, or just eating the cost

Comment on lines +227 to +228
pub console: Option<bool>,
pub file: Option<bool>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR describes what this does but doesn't provide the motivation.

I find this

  • confusing: it isn't very clear what these states mean and why you would use them
  • odd to have build analysis and to be able to turn off file
  • unclear on what purpose this is meant to serve, especially at this point

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is config doc update 3df1405.

Updated the PR description. Thanks for the nudge.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

User may want to pipe build log to stdout and process them in a stream manner in real time, rather than in a log file.

As I've said before, I want us to unify the build log and json message format, so how do decide what is a "build log" and a "regular message" in that future? I'd rather just wait, see how stabilization goes on this, and evaluate always putting these messages out.

Output to stdout so we can have a replacement for the unstable --timings=json option.

Do we need to have feature parity with that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather just wait, see how stabilization goes on this, and evaluate always putting these messages out.

That is fair. We should wait and see.

Add output control for build analysis logs.

Example config:

```toml
[build.analysis]
enabled = true
console = true
file = false
```

Console output is only enabled when `--message-format` has a JSON
option.

Note that logging is best-effort for now.
If there is any broken pipe, no error or warning will show
@weihanglo
Copy link
Member Author

Closed as we want to wait and see how we build logs and JSON message should work with each other in the future.

Also, the original motivation of this was finding a good replacement for --timings=json but that is unstable, and people have workaround (with a bit more works) with -Zbuild-analysis, so the motivation was gone.

Thanks for the review!

@weihanglo weihanglo closed this Dec 19, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 19, 2025
github-merge-queue bot pushed a commit that referenced this pull request Jan 7, 2026
### What does this PR try to resolve?

Arguments to remove it

* The `--timings=json` is obsolete as `-Zbuild-analysis` logging is
  a more approachable option, which doesn't need passing
  `--timings=json` ahead of time.
* There is no support infra built around `--timings=json` yet,
  while for `-Zbuild-analysis` we have `cargo report timings` already.
* `--timings=json` is a UI feature inherently unstable, and has no
tests.

Counterargument:

* `--timings=json` outputs to stdout, but there is no  alternative yet
  also outputs to stdout.
<#16418> was an attempt to add
that back,
  but we then decide to punt until seeing requests or needs.

### How to test and review this PR?

* `cargo help build` and check the manpage
* `cargo build --help` and cehck the help text
* `cargo build --timings` and it works
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-documenting-cargo-itself Area: Cargo's documentation A-timings Area: timings Z-build-analysis Nightly: build-analysis

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants