Make measureme tools available as rustup component

[michaelwoerister]

The measureme version in the compiler and the corresponding tools must stay in sync in order for things to be really reliable. I suspect that the best way of doing this in the rustc ecosystem is to make the measureme suite available as a rustup component. This would have the following benefits:

• Compiler and tools would stay in sync "automatically".
• It's easy to use measureme with multiple toolchains on the same system (which would be a pain otherwise).
• It's simple for end users to get ahold of the tools.
  • This might also extend to perf.rlo which also needs a compatible version of the tools involved.

@Mark-Simulacrum & @wesleywiser, do you agree that the rustup component would actually have these benefits? (My knowledge about rustup components is mostly accidental)

I assume that measureme would have to be part of the main Rust repository somehow (as a submodule probably), which seems fine.

[wesleywiser]

That seems correct to me but I don't know much about rustup components.

[Mark-Simulacrum]

I think this is probably the best best, yes, though I think if we're to do this we'll want to always ship measureme (like Cargo, not like RLS/Clippy) and probably also run some tests. For perf, at least, it's really important that self profile works reliably if we're to have it.

[michaelwoerister]

Good point, @Mark-Simulacrum. Having it in-tree in some form will make testing easier.

[eddyb]

I'm wondering two things regarding this:

• the README could suggest this instead of cargo build:

  cargo install --git https://github.com/rust-lang/measureme summarize
  

• do we really need these to be separate? couldn't rustc have some flags to handle the common usecases?

[michaelwoerister]

We initially had analysis inside of rustc but that was a huge amount of overhead and skewed the results. I also dislike the idea of rustc producing flamegraphs and stuff directly. I posted a proposal of how to make this ergonomic here: https://internals.rust-lang.org/t/compiler-profiling-survey/10969/18