Add debugging hooks for futures

[aturon]

Make it possible to debug deadlocks/lost wakeups by examining the graph of tasks and what they believe they're blocked on.

[aturon]

@cramertj can you sketch out the ideas from the All Hands?

[cramertj]

There's been some back and forth about the best way forward, but the original idea was to have a linked list of contextually relevant Debug types included in task::Context:

use std::fmt::Debug;

enum DebugList<'a> {
    Nil,
    Cons(&'a Debug, &'a DebugList<'a>),
}

task::Context would then include a with_debug function that borrowed from a task::Context and produced a new task::Context with one more element in the DebugList. Then, rather than having Clone as a supertrait of Waker, we'd add Waker::clone which took a DebugList so that Waker implementations could record the context of the task that is to be awoken by that Waker. The purpose of providing the debug information directly in the clone method (rather than a separate method) is to ensure that no wakeup is created without the appropriate debug info-- if the information is only provided sometimes, it's dramatically less useful for debugging wakeups that should exist, but don't.

There's also been talk of doing this outside of task::Context using a thread local and having Waker implementations pull from that, though that seems to me like it has more potential for negative performance impact.

[jsgf]

There's a few things I'd like to see:

• A way to inspect the internal states of Future state machines
• A way to inspect the dependency graph between them
• A way to get events as states change within the context of the dependency graph

And just because this is pure wishlist:

• This composes across crates with different origins
• Can be as similarly simple to implement as a #[derive()], but allows for more complex impls
• Cheap enough to always compile in, and can be dynamically enabled/disabled at runtime

We've (mostly @kulshrax) done some prototyping in house, and are mostly at the level of a tracing combinator approach, which is OK but it's limited in scope. I'd like to maintain dependency info, but the lack of a suitable context to hang it off has been hampering that effort (per-thread isn't suitable and per-task doesn't really work). The addition of an explicit context param to poll() makes that easier, which I guess is pretty close to what @cramertj is proposing.

[jsgf]

Oh, another thing that's pretty painful - some standard way to capture panics so they don't get lost. At the moment they just evaporate.

[sfackler]

@jsgf I think https://doc.rust-lang.org/std/panic/fn.set_hook.html may be what you're looking for there?

[jsgf]

@sfackler As a last resort, but its a bit global. I was thinking of something more per-executor.

[aidanhs]

One thing that I believe was mentioned (I think, trying to dredge my memory) at all hands was that could store your debuglist data by using a combinator, e.g. f1.debuginfo("foo").and_then(|_| f2.debuginfo(Bar { ... })).

This is pretty paged-out though and my recollection of the planned design of futures is hazy, so I may be misrepresenting the idea.