WIP fixing breaking change on poise (serenity-next branch)

[FabseGP]

Fixed accessing the ShardManager runners, but... don't know how to tackle

error[E0507]: cannot move out of `client.shard_manager` which is behind a shared reference
  --> src/framework/mod.rs:97:44
   |
97 |         self.shard_manager = Some(Arc::new(client.shard_manager));
   |                                            ^^^^^^^^^^^^^^^^^^^^ move occurs because `client.shard_manager` has type `serenity::gateway::ShardManager`, which does not implement the `Copy` trait

Serenity doesn't store shard_manager as an Arc, nor do shard_manager implement Copy or Clone (got changed in Serenity next-branch)

[simxnet]

You cannot Arc shard manager as it doesn't implement Copy

[FabseGP]

You cannot Arc shard manager as it doesn't implement Copy

That makes sense, but...

    /// Initialized to Some during construction; so shouldn't be None at any observable point
    shard_manager: Option<Arc<serenity::ShardManager>>,

the framework expects an Arc for shard_manager. I did try and remove the Arc line by line, but I ended with a breakage in src/dispatch/mod.rs:

error[E0308]: mismatched types
  --> src/dispatch/mod.rs:58:9
   |
57 |     pub fn shard_manager(&self) -> serenity::ShardManager {
   |                                    ---------------------- expected `serenity::gateway::ShardManager` because of return type
58 |         self.shard_manager.clone()
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `ShardManager`, found `&ShardManager`
   |
note: `serenity::gateway::ShardManager` does not implement `Clone`, so `&serenity::gateway::ShardManager` was cloned instead
  --> src/dispatch/mod.rs:58:9
   |
58 |         self.shard_manager.clone()
   |         ^^^^^^^^^^^^^^^^^^

(used to return Arc<serenity::ShardManager>)

More or less I'm stuck xD

[FabseGP]

currently I'm at adding a Mutex to shard_manager in Serenity (fork) and then passing Arc<Mutex> around, but that requires changing more than I like in Poise's framework

(as to why not just change it back to Arc, shard_manager now have methods that require interior mutability)

[cheesycod]

currently I'm at adding a Mutex to shard_manager in Serenity (fork) and then passing Arc around, but that requires changing more than I like in Poise's framework

(as to why not just change it back to Arc, shard_manager now have methods that require interior mutability)

Checked your fork. The mutex looks highly suspicious though and might cause deadlocks if code ever tries to lock the shard manager after starting the bot?