Support specify timings in .cargo/config

[Rustin170506]

What does this PR try to resolve?

close #10509

Support specify timings in .cargo/config.

How should we test and review this PR?

• unit test

[rust-highfive]

r? @ehuss

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

[Rustin170506]

@ehuss This PR is still being worked on, but before I add the documentation, I wanted to confirm with you that because these two options are not stable, I've marked the configuration as unstable as well. Is this correct? I want to make sure I'm on the right track. Could you please take a look? Thanks!

[ehuss]

Oh, sorry for the confusion. I don't think there is any need to make the config value itself unstable. It is pretty simple and straightforward.

[Rustin170506]

Oh, sorry for the confusion. I don't think there is any need to make the config value itself unstable. It is pretty simple and straightforward.

@ehuss Thank you for your reply! I have deleted it. This PR is ready to be reviewed.

[ehuss]

Thanks, looks good! Just need some updates to make sure the JSON option isn't stabilized.

[ehuss]

Thanks! Can you squash the commits?

@rust-lang/cargo This is a proposal to add and stabilize the build.timings config setting which provides a way to enable the timings report via config. This can be easier to use in a complex build system, or just to avoid passing the CLI option frequently.

[build]
timings = ["html"]

or CARGO_BUILD_TIMINGS=html environment variable.

The config uses an array. "html" is the only stable option. "json" is unstable. There could be other considerations for the type of the value (like a boolean or a string), but I feel like an array is the simplest, and is flexible. If more complex options are needed in the future, then the type can be overloaded.

I don't feel there is too much to consider, so I don't feel like it needs to be unstable.

@rfcbot fcp merge

[rfcbot]

Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Rustin170506]

Thanks! Can you squash the commits?

Done.

[joshtriplett]

--timings seems like a debugging option; what's the use case for enabling it in a config file?

[Rustin170506]

--timings seems like a debugging option; what's the use case for enabling it in a config file?

Debug and optimize many times in the development process?

[Rustin170506]

Also, I think this configuration would be helpful if there is a continuous integration system that is constantly getting timings reports.

[Rustin170506]

@Eh2406 @epage Could you please take a look? Thanks! 💚 💙 💜 💛 ❤️

[bors]

☔ The latest upstream changes (presumably #10753) made this pull request unmergeable. Please resolve the merge conflicts.

[Rustin170506]

The conflict has been resolved and if anyone can help move it forward, I would appreciate it.

[epage]

This feels like something more transient. The motivations listed in this PR sound more like speculation, so I reached out on the original Issue to the filer for what their intended motivation was.

[Rustin170506]

so I reached out on the original Issue to the filer for what their intended motivation was.

He said he just wanna set up all things in the config. What do you think? Should I close this PR?

This can be easier to use in a complex build system, or just to avoid passing the CLI option frequently.

Also, what do you think of this idea? Do you think it's useful?

[Rustin170506]

I am going to close this PR as the motivation is not clear. Thanks for your review and feedback.