Add API for overriding initial event_id before recording an event and bump version to 0.6.0

[michaelwoerister]

This PR adds a small piece of functionality that is needed for query key recording. In rustc we (will) use the DepNodeIndex as the virtual StringId that ends up being the event_id. However, the DepNodeIndex is often only generated after we already started recording the corresponding event. So we need a way of overwriting the event_id once we know what to actually set it to.

This PR also bumps the version to 0.6.0 for all crates in the repo. As @Mark-Simulacrum pointed out, it makes sense to have one version number for the entire workspace (with the expectation that the tools and libraries of the same version number are always compatible with each other).

r? @wesleywiser

[wesleywiser]

lgtm!

We should update the Changelog if you're planning to release 0.6. I believe the only PRs since then have been #93, #97, and #98.

We just recently bumped the measureme version in rustc and it has been causing some issues for perf.rlo. Do we need to bump it again or do you think there's more changes to be made before we should bump rustc's version?

[michaelwoerister]

We should update the Changelog if you're planning to release 0.6. I believe the only PRs since then have been #93, #97, and #98.

Yes, I'll do that. Generally speaking, I'm a bit conflicted about the changelog. Not sure if it's worth trouble.

We just recently bumped the measureme version in rustc and it has been causing some issues for perf.rlo. Do we need to bump it again or do you think there's more changes to be made before we should bump rustc's version?

Yes, I think the summarize tool was not updated in time. I also realized that the collector has to keep the tooling in sync with the compiler in some automated way if we want to support collecting profiles for older rustc versions that need older, matching versions of summarize. A rustup component is still my preferred approach for that.

Regarding the necessity of a version bump now: I'm not entirely sure if I'll be able to finish support for query keys before the end of the year (I only have next week left to do that), so I thought it would be good to land the current state in the compiler. It's not strictly necessary though. If @Mark-Simulacrum says it's too much of a hassle to do another version bump, we can also wait until query key support is fully implemented. The changes for that are rather self-contained and unlikely to need lots of rebasing.

[wesleywiser]

Yes, I'll do that. Generally speaking, I'm a bit conflicted about the changelog. Not sure if it's worth trouble.

I think I feel similarly. I've found it useful a few times and I think it's a good way to show off contributions from non-WG-self-profile members, but it's kind of a pain to update.

I also realized that the collector has to keep the tooling in sync with the compiler in some automated way if we want to support collecting profiles for older rustc versions that need older, matching versions of summarize.

This is a good point.

I thought it would be good to land the current state in the compiler. It's not strictly necessary though.

I don't have a strong opinion here but I think it would be good to reduce churn and issues for rustc. I'll defer to @Mark-Simulacrum's opinion on the question of bumping rustc's measureme version.

[bjorn3]

I also realized that the collector has to keep the tooling in sync with the compiler in some automated way if we want to support collecting profiles for older rustc versions that need older, matching versions of summarize.

Maybe add a dependency on the newer measureme to the collector before updating rustc, and then use the version number to choose between the two versions of the crate.