Added support for rustc self-profiling#4073
Conversation
0b0131c to
846dbe4
Compare
846dbe4 to
d4900c1
Compare
krasimirgg
left a comment
There was a problem hiding this comment.
This is very nice!
Let's also add a test (let's chat internally about the mechanics of testing this).
| "nightly compiler toolchain. The setting is configured from the command line via " + | ||
| "`--@rules_rust//rust/settings:zself_profile_events`." + | ||
| "The expected value format is `<prefix_filter>@<events_specification>`. Multiple uses of " + | ||
| "this flag are accumulated: " + |
There was a problem hiding this comment.
nit: is it intended that this sentence ends in :?
| "`--@rules_rust//rust/settings:zself_profile_events`." + | ||
| "The expected value format is `<prefix_filter>@<events_specification>`. Multiple uses of " + | ||
| "this flag are accumulated: " + | ||
| "If the target prefix matches with <prefix_filter>, `-Zself-profile` and `-Zself-profile-events` " + |
There was a problem hiding this comment.
Just confirming something: after reading the setup_zself_profile implementation, the event types are collected from the first matching filter:
For instance, here the event types would be foo:
--@rules_rust//rust/settings:zself_profile_events=//my/project@foo --@rules_rust//rust/settings:zself_profile_events=//my/project@bar
I think this is OK, but could you clarify? Especially in the context of the previous sentence "Multiple uses of this flag are accumulated" -- a user reading this may interpret this as that in the example above, both foo and bar are collected, so there's potential for confusion.
Introduced a new build setting,
--//rust/settings:zself_profile_events, to enable rustc's-Zself-profileand-Zself-profile-eventsflag. Rustnightlytoolchain is required for using this feature.The setting accepts patterns to match against crate labels or execution paths, allowing fine-grained control over which crates are profiled.
Profiling data is output to a
<crate_name>_self-profiledirectory.