-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make rmeta_required no longer depend on whether timing is enabled #10254
Conversation
This doesn't appear to affect the quality of the timing information at all. If there's additional information we need from rustc about what it's doing at any given time, we could add mechanisms to retrieve that information, but enabling timing shouldn't force building more than we otherwise would have.
(rust-highfive has picked a reviewer for you, use r? to override) |
@@ -604,7 +604,7 @@ impl<'a, 'cfg> Context<'a, 'cfg> { | |||
/// Returns whether when `unit` is built whether it should emit metadata as | |||
/// well because some compilations rely on that. | |||
pub fn rmeta_required(&self, unit: &Unit) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this now pull its weight as a separate function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ok for now in the sense that it keeps the field private to just this module
@bors: r+ |
📌 Commit 25d1480 has been approved by |
☀️ Test successful - checks-actions |
Just to be clear, this does change the output a little. In some cases where cargo does not use pipelining, the information about when codegen starts isn't included. For example: versus I think that should be fine, as it still shows up in most cases. It would be pretty easy to extend rustc to provide more information, would just need some thought on how to structure that and what information to obtain. |
If cargo/src/cargo/core/compiler/mod.rs Line 804 in 3897749
cargo/src/cargo/core/compiler/mod.rs Line 902 in 3897749
rmeta_required disables the mechanism by which -Ztimings figures out how long codegen takes without affecting affecting anything else.
|
@bjorn3 Ah, interesting! It sounds like we ought to ask rustc to emit that information unconditionally, then. |
Update cargo 10 commits in fcef61230c3b6213b6b0d233a36ba4ebd1649ec3..358e79fe56fe374649275ca7aebaafd57ade0e8d 2021-12-17 02:30:38 +0000 to 2022-01-04 18:39:45 +0000 - Make rmeta_required no longer depend on whether timing is enabled (rust-lang/cargo#10254) - The first version of pull request template (rust-lang/cargo#10218) - Stabilize the `strip` profile option, now that rustc has stable `-C strip` (rust-lang/cargo#10088) - Update docs for windows ssh-agent. (rust-lang/cargo#10248) - Fix typo: substract -> subtract (rust-lang/cargo#10244) - timings: Fix tick mark alignment (rust-lang/cargo#10239) - Remove unused lifetimes (rust-lang/cargo#10238) - Make levenshtein distance case insensitive. (rust-lang/cargo#10224) - [docs] Adds basic CI yaml for GitHub Actions (rust-lang/cargo#10212) - Add function for parsing already-read manifest (rust-lang/cargo#10209)
This doesn't appear to affect the quality of the timing information at
all.
If there's additional information we need from rustc about what it's
doing at any given time, we could add mechanisms to retrieve that
information, but enabling timing shouldn't force building more than we
otherwise would have.