Add support of having arguments on events.

[michaelwoerister]

This is implemented by encoding arguments as part of the event_id using the following grammar:

<event_id> = <label> {<argument>}
<label> = <text>
<argument> = '\x1E' <text>
<text> = regex([^[[:cntrl:]]]+) // Anything but ASCII control characters

This can be extended in the future to also encode the "category" that specify in rustc but don't use anywhere. The grammar uses ASCII control characters as separators. I'm not sure how much I like the grammar. It's something that works for now but I don't consider it great.

I'm debating whether event_id should get a new type struct EventId(StringId). That way we could ensure at compile time that only syntactically correct strings are used as event_ids...

r? @wesleywiser

[wesleywiser]

This looks great!

[wesleywiser]

I'm debating whether event_id should get a new type struct EventId(StringId). That way we could ensure at compile time that only syntactically correct strings are used as event_ids...

It seems like a good idea and it's also a little strange that we have EventIdBuilder but it doesn't actually create an EventId type, it just returns StringIds.

My only concern would be that it might make using api's that take StringId slightly more cumbersome.

I don't think we have to block landing this PR on that though.

[michaelwoerister]

I added the EventId wrapper in 9daf790 and I'm pretty pleased with it. It's not much of a hassle to use it (usually you go through the EventIdBuilder anyway) and it really makes things a lot harder to get wrong. That includes mixing up the event_id and event_kind parameters in various profiler methods, something would could also easily happen before this PR.

I also made the grammar a bit simpler. There's no real reason to "future-proof" it the way I did initially. We can just change it when the time comes.