| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules are now separated into a fashion where the library can be used
for most use cases, without needing to compile the rest.
The core of serenity, with no features enabled, contains only the
struct (model) definitions, constants, and prelude. Models do not have
most functions compiled in, as that is separated into the `model`
feature.
The `client` module has been split into 3 modules: `client`, `gateway`,
and `http`.
`http` contains functions to interact with the REST API. `gateway`
contains the Shard to interact with the gateway, requiring `http` for
retrieving the gateway URL. `client` requires both of the other features
and acts as an abstracted interface over both the gateway and REST APIs,
handling the event loop.
The `builder` module has been separated from `utils`, and can now be
optionally compiled in. It and the `http` feature are required by the
`model` feature due to a large number of methods requiring access to
them.
`utils` now contains a number of utilities, such as the Colour struct, the
`MessageBuilder`, and mention parsing functions.
Each of the original `ext` modules are still featured, with `cache` not
requiring any feature to be enabled, `framework` requiring the `client`,
`model`, and `utils`, and `voice` requiring `gateway`.
In total the features and their requirements are:
- `builder`: none
- `cache`: none
- `client`: `gateway`, `http`
- `framework`: `client`, `model`, `utils`
- `gateway`: `http`
- `http`: none
- `model`: `builder`, `http`
- `utils`: none
- `voice`: `gateway`
The default features are `builder`, `cache`, `client`, `framework`,
`gateway`, `model`, `http`, and `utils`.
To help with forwards compatibility, modules have been re-exported from
their original locations.
|
| |
|
|
|
| |
If a user returns at the end of a `command!` macro block, the library's return
value will never be processed, as it's unreachable. Instead of warning for this,
allow it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The help commands don't actually need to have the arguments passed by
value, so passing them by reference is fine.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While selfbots have always been "roughly tolerated", lately they have
been tolerated to less of a degree.
The simple answer is to no longer support selfbots in any form. This is
done for a few of reasons: 1) in anticipation of selfbots no longer
being tolerated; 2) there are few reasons why one should make a selfbot
in Rust and not a scripting language; 3) there are alternatives
(i.e. discord-rs) that still support userbots. Selfbots are simply not
a goal of the maintainer of serenity.
Upgrade path:
Don't use selfbots with serenity. Use discord-rs instead.
The following has been removed:
Enums:
- `RelationshipType`
Structs:
- `FriendSourceFlags`
- `ReadState`
- `Relationship`
- `SearchResult`
- `SuggestionReason`
- `Tutorial`
- `UserConnection`
- `UserGuildSettings`
- `UserSettings`
Removed the following fields:
- `CurrentUser::mobile`
- Ready::{
analytics_token,
experiments,
friend_suggestion_count,
notes,
read_state,
relationships,
tutorial,
user_guild_settings,
user_settings,
}
Removed the following methods:
- `Client::login_user`
Deprecated `Client::login_bot` in favour of `Client::login`.
Removed `client::LoginType`.
The following no longer take a `login_type` parameter:
- `Context::new`
- `Shard::new`
`Shard::sync_guilds` has been removed.
The `client::Error::{InvalidOperationAsBot, InvalidOperationAsUser}`
variants have been removed.
The following event handlers on `Client` have been removed:
- `on_friend_suggestion_create`
- `on_friend_suggestion_delete`
- `on_relationship_add`
- `on_relationship_remove`
- `on_user_guild_settings_update`
- `on_note_update`
- `on_user_settings_update`
The following `client::rest` functions have been removed:
- `ack_message`
- `edit_note`
- `get_user_connections`
- `search_channel_messages`
- `search_guild_messages`
The following `client::rest::ratelimiting::Route` variants have been
removed:
- `ChannelsIdMessagesSearch`
- `GuildsIdMessagesSearch`
- `UsersMeConnections`
The following fields on `ext::cache::Cache` have been removed:
- `guild_settings`
- `relationships`
- `settings`
while the following methods have also been removed:
- `update_with_relationship_add`
- `update_with_relationship_remove`
- `update_with_user_guild_settings_update`
- `update_with_user_note_update`
- `update_with_user_settings_update`
The following methods have been removed across models:
- `ChannelId::{ack, search}`
- `Channel::{ack, search}`
- `Group::{ack, search}`
- `GuildChannel::{ack, search}`
- `GuildId::{search, search_channels}`
- `Guild::{search, search_channels}`
- `Message::ack`
- `PartialGuild::{search, search_channels}`
- `PrivateChannel::{ack, search}`
- `UserId::{delete_note, edit_note}`
- `User::{delete_note, edit_note}`
The following events in `model::events` have been removed:
- `FriendSuggestionCreateEvent`
- `FriendSuggestionDeleteEvent`
- `MessageAckEvent`
- `RelationshipAddEvent`
- `RelationshipRemoveEvent`
- `UserGuildSettingsUpdateEvent`
- `UserNoteUpdateEvent`
- `UserSettingsUpdateEvent`
Consequently, the following variants on `model::event::Event` have been
removed:
- `FriendSuggestionCreate`
- `FriendSuggestionDelete`
- `MessageAdd`
- `RelationshipAdd`
- `RelationshipRemove`
- `UserGuildSettingUpdate`
- `UserNoteUpdate`
- `UserSettingsUpdate`
The `utils::builder::Search` search builder has been removed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the Context having many methods removed, the doctests were
failing.
Update the doctests to use alternative methods to accomplish the same.
Example:
Before:
```rust
context.say("hi");
```
After:
```rust
message.channel_id.say("hi")
```
|
| |
|
|
|
|
| |
Most of the methods in the Context were for interacting with the related
ChannelId, but these methods have been re-implemented on ChannelId
itself, and is now the preferred (and now only) way to interact with it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve the cache by keeping track of new maps, making other maps have
`Arc<RwLock>` values, optimizing already-existing methods, and take advantage
of new, more efficient retrievals (e.g. simply keying a value from a map rather
than iterating over vecs or maps and then itering over another vec).
Keep track of two new maps in the cache:
- **channels**: a map of all guild channels that exist, so that they can be
efficiently found, and so a message's guild can be efficiently found
- **users**: a map of all users that exist, so that it can be shared across
all members and presences
Other cache fields now have `Arc<RwLock>` values:
- `groups`
- `guilds`
- `private_channels`
`Cache::unavailable_guilds` is now a `HashSet<GuildId>` instead of a
`Vec<GuildId>`. This should slightly optimize removals/insertions for large
bots.
`ext::cache::ChannelRef` has been removed as it became equivilant in
functionality to `model::Channel`. Also, `model::Channel` now has all variant
data encased in `Arc<RwLock>`s. E.g., `Channel::Group(Group)` is now
`Channel::Group(Arc<RwLock<Group>>)`.
Some model struct fields are now wrapped in an `Arc<RwLock>`. These are:
- `Group::recipients`: `HashMap<UserId, User>` -> `HashMap<UserId, Arc<RwLock<User>>>`
- `Guild::channels`: `HashMap<ChannelId, GuildChannel>` -> `HashMap<ChannelId, Arc<RwLock<GuildChannel>>>`
- `Member::user`: `User` -> `Arc<RwLock<User>>`
- `PrivateChannel::recipient`: `User` -> `Arc<RwLock<User>>`
Some (cache-enabled) event handler signatures have changed to use
`Arc<RwLock>`s:
- `Client::on_call_delete`
- `Client::on_call_update`
- `Client::on_guild_delete`
- `Client::on_guild_update`
Many function signatures have changed:
- `Cache::get_call` now returns a `Option<Arc<RwLock<Call>>>` instead of a
`Option<&Call>`
- `Cache::get_channel` now returns a `Option<Channel>` instead of a
`Option<ChannelRef>`. This now also retrieves directly from the
`Guild::channels` instead of iterating over guilds' for a guild channel
- `Cache::get_guild` now returns a `Option<Arc<RwLock<Guild>>>` instead of a
`Option<&Guild>`
- `Cache::get_guild_channel` now returns a `Option<Arc<RwLock<GuildChannel>>>`
instead of a `Option<&GuildChannel>`
- `Cache::get_group` now returns a `Option<Arc<RwLock<Group>>>` instead of a
`Option<&Group>`
- `Cache::get_member` now returns a `Option<Member>` instead of a
`Option<&Member>`, due to guilds being behind a lock themselves
- `Cache::get_role` now returns a `Option<Role>` instead of a `Option<&Role>`
for the above reason
- `Cache::get_user` now returns a `Option<Arc<RwLock<User>>>` instead of a
`Option<&User>`
- `GuildId::find` now returns a `Option<Arc<RwLock<Guild>>>` instead of a
`Option<Guild>`
- `UserId::find` now returns a `Option<Arc<RwLock<User>>>` instead of a
`Option<User>`
- `Member::display_name` now returns a `Cow<String>` instead of a `&str`
A new cache method has been added, `Cache::get_private_channel`, to retrieve a
`PrivateChannel`.
The `Display` formatter for `Channel` has been optimized to not clone.
|
| |
|
|
|
|
|
|
|
| |
When attempting to use a named argument with a type of String, the
framework will try to parse the received argument - a String - into a
String. This can never fail, so Rust warns that the `Err` arm of the
`match` can never be reached.
Let's just ignore that and everything will be fine.
|
| | |
|
| |
|
|
|
|
| |
The context is now strictly in relation to the context of the current
channel related to the event, if any. See Context::say for a list of
events that the context can be used for.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Also the dreaded `ctx <<= "something"` which is actually a mistake.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The framework would take the length of the prefix in bytes, and then
search for a command either directly after the byte length _and_ plus
one for a command. Instead, ensure that the message is longer
than the prefix.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The framework would ignore the `before` function if the command was not
ran by an owner. Instead, flip the conditions so that it's always run,
and then the result is succeeded by an owner check.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Implement command groups
* change to ref mut
* Implement framework API.
* Remove commands field
* Make it all work
* Make example use command groups
* Requested changes
* Implement adding buckets
* Add ratelimit check function
* Finish everything
* Fix voice example
* Actually fix it
* Fix doc tests
* Switch to result
* Savage examples
* Fix docs
* Fixes
* Accidental push
* 👀
* Fix an example
* fix some example
* Small cleanup
* Abstract ratelimit bucket logic
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds multiple configurations to the command builder, and adds methods
to various structs.
Context::get_current_user is a shortcut to retrieve the current user
from the cache.
Message::get_member retrieves the member object of the message, if sent
in a guild. Message::is_private checks if the message was sent in a
Group or PrivateChannel.
User::member retrieves the user's member object in a guild by Id;
Adds 6 configurations to the command builder:
- dm_only: whether the command can only be used in direct messages;
- guild_only: whether the command can only be used in guilds;
- help_available: whether the command should be displayed in the help
list;
- max_args: specify the maximum number of arguments a command must be
given;
- min_args: specify the minimum number of arguments a command must be
given;
- required_permissions: the permissions a member must have to be able
to use the command;
|
| | |
|
| |
|
|
|
| |
Add a command builder, which can take arguments such as multiple checks,
quoted arguments, and multiple prefix support, as well as dynamic
prefixes per context.
|
| |
|
|
| |
This will allow the command macro to be used in sub-modules.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These hooks will each be run prior to or after the command, and will
finish execution before executing the command.
These can be configured in a Framework via:
```rs
client.with_framework(|f| f
.before(|_context, message, _command_name| {
println!("Got command '{}'", command_name);
})
.after(|_context, _message, command_name| {
println!("Finished command '{}'", command_name);
}));
```
This does introduce a backwards compatibility break, by requiring
commands' Context/Message to be borrowed
Upgrade path:
If not using the `command!` macro, modify command signatures from:
```rs
fn some_command(context: Context, message: Message, args: Vec<String>)
```
to
```rs
fn some_command(context: &Context, message: &Message, args: Vec<String>)
```
|