Simple logging methods

[nikomatsakis]

This is an experimental branch. It introduces a method salsa_event into the Database trait that defaults to a no-op. This event is given a closure (event_fn) which, when called, will produce information about what is happening -- the purpose of the closure is to defer any real work (notably, cloning the descriptor) if the salsa_event is not enabled.

This could be used for various purposes. For example, tests can override salsa_event and log the events somewhere, using them to reconstruct what happened. I was imagining though that we might provide some higher-level consumers at some point.

This branch uses salsa_event in the parallel test to force one thread blocks for another, which we could not do before.

[nikomatsakis]

One thing I did not like about this interface: there is no way to inspect the kind of the event before you invoke event_fn. An earlier draft had multiple methods (one per callback kind) -- maybe that is better, and they should have default implements that invoke the "default" salsa_event callback. Alternatively, salsa::Event could have a lifetime associated with it, or use Cow values, but those options seem kind of annoying.

[nikomatsakis]

OK, so, I added Debug impls and also added per-event methods (salsa_event_foo) so that you can easily intercept just the event kinds that you like. I also refactored the Event structure to move some more common data into one place (e.g., the descriptor that appears in every event).

I'm feeling pretty "ok" about this change though mildly nervous about some of the details (e.g., just when do events fire etc).

I'd like to have a "gc collected" event but that's a bit of a pain to thread through (doable, just takes a bit more thought).

I'd prefer if the "event delivery" methods were in a separate trait, but lacking specialization there is no easy way to do that without all database implementations having to add an impl for it, which don't really want.

I guess overall I'm inclined to merge but this seems like the sort of thing we might want to revisit before 1.0 and reconsider.

[nikomatsakis]

OK, I've removed the "per event kind" methods. That seemed like a lot more surface area than was warranted.

[kleimkuhler]

I like these changes. I agree that the utility of a "gc collected" event would be nice. I have a few questions about where the complexity occurs specifically for that, but I'm sure it will become a little more clear as I use the events.