Daniel Silverstone

Sorry for the delay, work has been frantic for the past month or so. This kind of problem is because Docker often doesn't cope well with removing things from one...

After a discussion on IRC, here's some clarifying commentary: We assume two operations which need to be supported here: 1. **completion** which is exactly what `` does today - i.e....

To reiterate a call for this, we'd *love* to have this in `rustup` so we could offer more localised completions (e.g. for `+foo` to complete over installed toolchains).

We added this so that we'd stop rewriting the bits of `build.rs` which dealt with gdk backends. If the new `system_deps` stuff avoids that generated content entirely then that seems...

As an addendum, it'd be fine if it were possible to accept the invitation from the `Room::Left` but I think the API is trying to be an opinionated typestate API...

(Note it won't let me because the bot is invited to the room. If I disinvite the bot then the `forget` call doesn't error but the bot *still* ends up...

Final update (I hope) - If I enumerate the rooms after the initial sync_once and then forget all the rooms, and *then* kill the process and restart it, then I...

Without a semi-reliable way to trigger this, there's not a lot we can do to diagnose. The `unwrap()` in question occurs normally in another thread and so should not cause...

@rbtcollins Yes, that's exactly the location, I just wonder if a non-primary thread panicing has caused the real error to get lost, perhaps being more graceful here might result in...

@ChrisDenton 1.24.3 included https://github.com/rust-lang/rustup/pull/2782 which *should* have fixed that circumstance. Are you running 1.24.3 and if so could you please tell me the exact variant of rustup you are running,...