aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Execute framework commands in a ThreadPoolZeyla Hellyer2018-01-211-17/+21
| | | | | | | | 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.
* Fix `has_all_requirements` (#245)Lakelezz2018-01-211-1/+1
| | | This fixes the behaviour of help-commands not showing in dms.
* Add `animated` to `Emoji` and `ReactionType`Zeyla Hellyer2018-01-213-6/+31
| | | | | | | | 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.
* Fix docs for User::has_roleNikita Pekin2018-01-051-3/+4
| | | | | Update the docs for `User::has_role` to reflect that `Into<GuildContainer>` is only implemented for `PartialGuild`, `GuildId`, and `u64`, not `Guild`.
* Release v0.4.5v0.4.5Zeyla Hellyer2017-12-091-2/+1
|
* Remove EditRole::default implementationZeyla Hellyer2017-12-091-29/+1
| | | | | Removes the custom implementation for `EditRole`, instead deriving Default.
* Fix remaining deserializersZeyla Hellyer2017-12-091-2/+2
| | | | | | 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.
* Fix snowflake deserializerZeyla Hellyer2017-12-091-2/+2
| | | | | | | | | | | | | | | | | | | 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.
* Fix doctests for a variety of feature targetsZeyla Hellyer2017-11-014-8/+33
|
* Fix no-client cache testsZeyla Hellyer2017-11-014-23/+45
| | | | | There were a few doctests in the cache module that relied on the client module, so instead feature-gate the doctests.
* Fix no-parking_lot compilationZeyla Hellyer2017-11-011-1/+2
| | | | | | Fixes compilation without the `parking_lot` crate compiled. The prelude re-exposed `parking_lot`'s `Mutex` and `RwLock`, but didn't do so conditionally.
* Use consistent token names in examplesZeyla Hellyer2017-11-015-5/+5
| | | | | The names of environment variable tokens in the examples differed, so this makes them all use the same name.
* Fix ping bot example (#211)Ben2017-10-311-1/+6
|
* Make Member::permissions return guild permissionsZeyla Hellyer2017-10-311-11/+3
| | | | | | 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.
* Slightly clarify ratelimiting documentationZeyla Hellyer2017-10-301-2/+2
|
* Fix extraneous whitespaceZeyla Hellyer2017-10-301-1/+1
|
* Rename `Guild::permissions_for`->`permissions_in`Zeyla Hellyer2017-10-305-8/+19
| | | | | | Rename `Guild::permissions_for` to `Guild::permissions_in`, deprecating `Guild::permissions_for` which is only an inline method to `permissions_in`.
* Guild::has_perms: use Guild::member_permissionsZeyla Hellyer2017-10-301-22/+14
| | | | | | 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 Guild::member_permissionsZeyla Hellyer2017-10-301-0/+51
| | | | | | 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.
* Add some docs to `BanOptions`acdenisSK2017-10-301-0/+1
|
* Fix shard shutdown via ContextZeyla Hellyer2017-10-294-8/+46
| | | | | | | | | | | | | | | | | | | | 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 #206 (#207)Uninteresting Account2017-10-292-11/+28
|
* Fall back to `str::parse` if `parse_username` failsacdenisSK2017-10-241-3/+4
|
* Fix User::has_roleZeyla Hellyer2017-10-241-1/+5
| | | | | | | | | 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.
* Add a debug impl for `DispatchError`acdenisSK2017-10-231-0/+25
| | | | | | 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
* Properly update emojis, fix shard retries, fix csLakelezz2017-10-233-6/+22
| | | | | | | * 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`.
* Add "zero-copy" parsingacdenisSK2017-10-212-1/+83
|
* Fix clippy warningsMei Boudreau2017-10-191-17/+14
|
* Fix shard connectionZeyla Hellyer2017-10-191-29/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Deprecate some text-only Channel methodsZeyla Hellyer2017-10-191-0/+11
| | | | | | | | | | | | | | | | | | | 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`
* Re-export parking_lot::{Arc, Mutex} from preludeZeyla Hellyer2017-10-191-0/+1
| | | | | | 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.
* Implement changing a role's position (#201)Ken Swenson2017-10-193-0/+59
|
* Add a missing breakacdenisSK2017-10-181-0/+1
|
* `assert` -> `assert_eq`acdenisSK2017-10-181-2/+2
|
* Add `PartialEq` impls and doc tests to `Args`acdenisSK2017-10-181-1/+154
|
* Use the underlaying integer value of a `ChannelType` variantacdenisSK2017-10-171-1/+1
|
* defer to `delete_message` if there's just one message to deleteacdenisSK2017-10-162-4/+8
|
* Use update syntax for Shard (#195)Edward Yang2017-10-161-22/+29
|
* Hash and do equality on just the id for `User`acdenisSK2017-10-151-1/+17
|
* Feature-flag extern crates behind their nameZeyla Hellyer2017-10-141-10/+10
| | | | | | | | | | | | | | | | | | | | | | | An issue with modifying what features enable compilation of what crates was possible due to crates being feature-flagged behind a module name instead of their own name. Instead of writing cfg features for crates as: ```rust \#[cfg(feature = "utils")] extern crate base64; ``` Write the feature name as its own name: ```rust \#[cfg(feature = "base64")] extern crate base64; ``` This way, crates can simply have compilation enabled in the project's features section in the `Cargo.toml` file.
* Add try_opt macro for substituteMei Boudreau2017-10-123-12/+13
|
* Optimize Member::rolesMei Boudreau2017-10-121-21/+11
|
* Help-features display `Aliases` and list information for `Aliases`. (#190)Lakelezz2017-10-121-60/+80
|
* Fix clippy lintsZeyla Hellyer2017-10-1120-99/+102
|
* Make `has_correct_permissions`, `has_correct_roles` and ↵Lakelezz2017-10-102-3/+3
| | | | `has_all_requirements` public. (#188)
* Add an iterator for `Args`acdenisSK2017-10-101-9/+33
|
* Add some docs to `Args`acdenisSK2017-10-101-0/+4
|
* Variety of methods to search for `Member`. (#187)Lakelezz2017-10-101-12/+218
|
* Reset shard heartbeat state on resumeZeyla Hellyer2017-10-091-0/+2
| | | | | | | | | | | | | When a resume is received, the heartbeat state would not be reset. This state includes: - whether the last heartbeat was acknowledged - when the last heartbeat was sent - when the last heartbeat acknowledgement was received This resulted in the bot re-IDENTIFYing after a Resumed event was received. To fix this issue, reset them when a Resumed event is received.
* Make the client threadpool user-customizableZeyla Hellyer2017-10-094-15/+38
| | | | | | In addition to making the threadpool used by client shards customizable by the user, make only a single threadpool (as opposed to one per shard) and share it across all shards.
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-19 21:00:12 +0000