| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
The v0.5.x branch threadpools commands and events in the same pool, but
this isn't possible in the v0.4.x branch due to backwards compatibility.
To resolve this, create a second threadpool for just the framework.
Closes #250.
|
| | |
|
| |
|
| |
This fixes the behaviour of help-commands not showing in dms.
|
| | |
|
| |
|
|
|
|
|
|
| |
Adds an animated structfield to `Emoji` and `ReactionType`'s `Custom`
variant, which defaults to false if not present.
A test has been added for deserializing it, taken from a REST API GET
Emojis response.
|
| |
|
|
|
| |
Update the docs for `User::has_role` to reflect that
`Into<GuildContainer>` is only implemented for `PartialGuild`,
`GuildId`, and `u64`, not `Guild`.
|
| | |
|
| | |
|
| |
|
|
|
| |
Removes the custom implementation for `EditRole`, instead deriving
Default.
|
| |
|
|
|
|
| |
Following up on the recent commit to fix the snowflake types'
deserializers, this commit fixes the rest of the library's usage of
deserializers in the same manner.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes snowflake deserializers (ChannelId, UserId, etc.) by switching
from a usage of `deserialize_u64` to `deserialize_any`.
Our usage of `deserialize_u64` was incorrect and the erroneous behaviour
was fixed in serde_json v1.0.8. We were essentially telling serde that
the received type was a u64, when in fact it can be multiple types
(strings, u64, or an i64 just in case).
This resulted in errors like:
```
Client error: Json(ErrorImpl { code: Message("invalid type: string
\"317727377985634305\", expected identifier"), line: 1, column: 100 })
```
Due to this, simple operations such as even connecting a client failed.
|
| | |
|
| | |
|
| |
|
|
|
| |
There were a few doctests in the cache module that relied on the client
module, so instead feature-gate the doctests.
|
| |
|
|
|
|
| |
Fixes compilation without the `parking_lot` crate compiled. The prelude
re-exposed `parking_lot`'s `Mutex` and `RwLock`, but didn't do so
conditionally.
|
| |
|
|
|
| |
The names of environment variable tokens in the examples differed, so
this makes them all use the same name.
|
| | |
|
| |
|
|
|
|
| |
Fixes what is realistically a bug where `Member::permissions` would
retrieve the permissions for the Member in the default channel of the
guild. This now only returns the guild-level permissions of the member.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Rename `Guild::permissions_for` to `Guild::permissions_in`, deprecating
`Guild::permissions_for` which is only an inline method to
`permissions_in`.
|
| |
|
|
|
|
| |
Make `Guild`'s internal method `has_perms` go through
`Guild::member_permissions` to check permissions, since all method that
use it don't need channel-specific permissions.
|
| |
|
|
|
|
| |
Add a method on the Guild for calculating only a member's guild-only
permissions, not including the permissions for either the default
channel or any specific channel.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the shard shutdown via the Context. This works by setting a
"shutdown" field on the Shard struct as being true, indicating that the
Shard has shutdown. The Shard Runner detects this and requests a
shutdown from the Shard Manager.
The ideal solution here would be to add a "Shutdown" variant to
serenity::gateway::ConnectionStage, but that would be a breaking change,
so we instead need to opt for adding a new struct to gateway::Shard.
The Shard Manager has also been updated to only attempt the shutdown of
a shard if it doesn't already know for certain that it shut itself down,
which avoids an error logged saying that there was an error sending a
shutdown message to its Shard Runner.
When all shards have been shutdown (for most bots, this will only be
one), the Shard Manager will end and the Client will stop its
operations, returning thread control to the user.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fix the return value of the function by properly checking whether the
user has the role in the given guild.
The function made the erraneous mistake of simply checking if the given
guild had the role by Id, not whether the _member in the given guild_
had the role by Id.
|
| |
|
|
|
|
| |
Why this was hand-made instead of derived is because of `CheckFailed`'s content, which is mostly `Command` not also deriving `Debug`; except that even `Command` has a trouble maker that would force us to do this hand-made anyway, `checks`.
Fixes #204
|
| |
|
|
|
|
|
| |
* If a guild's emojis are being altered, Serenity will straight up use the new `HashMap` instead of just extending.
If `connect()` returns an `Err`, it will retry connecting.
Cleaned up `help_command.rs`.
|
| |
|
|
|
|
|
| |
Update the following dependencies:
- `base64` from `~0.6` to `~0.7`
- rust-websocket fork from `0.0.1` to `0.0.2`
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes shard connections by removing the Default implementation for
Shards.
This was because when instantiating a Shard, `..Default::default()`
syntax was used, which calls the `Default` implementation of the struct
and moves the necessary values over to the overlying instantiation.
When using `..Default::default()` syntax, all values in the Default
implementation are instantiated, even ones that could be deemed
unnecessary.
For example, in the following sample code:
```rust
struct Foo {
x: bool,
y: bool,
}
impl Default for Foo {
fn default() -> Self {
Self {
x: true,
y: true,
}
}
}
// ...
let foo = Foo {
x: false,
..Default::default()
};
```
`Foo::x` will still be instantiated in the Default implementation
despite a value being set in the user's instantiation of Foo.
This causes WebSocket client instantiation to be invalid in the Default
instantiation, because the WebSocket instantiated has no base URL,
causing an error to be returned.
This commit resolves this issue by simply not having a Default
implementation - due to the fact that a default implementation will
never be valid and successful - and instead set all values in
`Shard::new`.
Notes: This issue surfaced with commit
fcc4e2ce2e523248ed33c9f4853d3485cbc9b6e6 (PR #195).
Closes #203.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some methods on `model::Channel` are only for text channels. Methods on
Channel should be applicable to all channel types.
Deprecates the following methods on `model::Channel`:
- `create_reaction`
- `delete_message`
- `delete_reaction`
- `edit_message`
- `message`
- `messages`
- `reaction_users`
- `say`
- `send_files`
- `send_message`
- `unpin`
|
| |
|
|
|
|
| |
These two types are used in public APIs, and so by re-exporting them it
makes it easier for the user to use them without needing to depend on
`parking_lot` themselves.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|