| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Move the unit tests into the relevant source files. There's no need for them to
be seprate, especially when the `tests` directory is meant to be for integration
tests.
The deserialization tests that include JSON files are still in the `tests` dir,
along with the public prelude re-export tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
By negating hashing altogether.
The increase is around 1000-ish nanoseconds saved.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `model` module has historically been one giant module re-exporting
all of the model types, which is somewhere around 100 types. This can be
a lot to look at for a new user and somewhat overwhelming, especially
with a large number of fine-grained imports from the module.
The module is now neatly split up into submodules, mostly like it has
been internally since the early versions of the library. The submodules
are:
- application
- channel
- error
- event
- gateway
- guild
- id
- invite
- misc
- permissions
- prelude
- user
- voice
- webhook
Each submodule contains types that are "owned" by the module. For
example, the `guild` submodule contains, but not limited to, Emoji,
AuditLogsEntry, Role, and Member. `channel` contains, but not limited
to, Attachment, Embed, Message, and Reaction.
Upgrade path:
Instead of glob importing the models via `use serenity::model::*;`,
instead glob import via the prelude:
```rust
use serenity::model::prelude::*;
```
Instead of importing from the root model module:
```rust
use serenity::model::{Guild, Message, OnlineStatus, Role, User};
```
instead import from the submodules like so:
```rust
use serenity::model::channel::Message;
use serenity::model::guild::{Guild, Role};
use serenity::model::user::{OnlineStatus, User};
```
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Builders would keep a `serde_json::Map<String, Value>`, which would
require re-creating owned strings for the same parameter multiple times
in some cases, depending on builder defaults and keying strategies.
This commit uses a `std::collections::HashMap<&'static str, Value>`
internally, and moves over values to a `serde_json::Map<String, Value>`
when it comes time to sending them to the appropriate `http` module
function.
This saves the number of heap-allocated string creations on most
builders, with specific performance increase on `builder::CreateMessage`
and `builder::CreateEmbed` & co.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current build system is rudimentary, incomplete, and rigid, offering
little in the way of customizing decoding options.
To solve this, switch to using serde-derive with custom Deserialization
implementations. This allows very simple deserialization when special
logic does not need to be applied, yet allows us to implement our own
deserialization logic when required.
The problem with the build system was that it built enums and structs
from YAML files. This is not so good, because it requires creating a
custom build system (which was rudimentary), creating "special struct
configs" when logic needed to be ever so slightly extended (rigid), and
if special logic needed to be applied, a custom deserialization method
would have been needed to be made anyway (incomplete).
To solve this, switch to serde-derive and implementing Deserialize
ourselves where required. This reduces YAML definitions that might
look like:
```yaml
---
name: Group
description: >
A group channel, potentially including other users, separate from a [`Guild`].
[`Guild`]: struct.Guild.html
fields:
- name: channel_id
description: The Id of the group channel.
from: id
type: ChannelId
- name: icon
description: The optional icon of the group channel.
optional: true
type: string
- name: last_message_id
description: The Id of the last message sent.
optional: true
type: MessageId
- name: last_pin_timestamp
description: Timestamp of the latest pinned message.
optional: true
type: string
- name: name
description: The name of the group channel.
optional: true
type: string
- name: owner_id
description: The Id of the group channel creator.
type: UserId
- name: recipients
description: Group channel's members.
custom: decode_users
t: UserId, Arc<RwLock<User>>
type: hashmap
```
to:
```rs
/// A group channel - potentially including other [`User`]s - separate from a
/// [`Guild`].
///
/// [`Guild`]: struct.Guild.html
/// [`User`]: struct.User.html
pub struct Group {
/// The Id of the group channel.
#[serde(rename="id")]
pub channel_id: ChannelId,
/// The optional icon of the group channel.
pub icon: Option<String>,
/// The Id of the last message sent.
pub last_message_id: Option<MessageId>,
/// Timestamp of the latest pinned message.
pub last_pin_timestamp: Option<String>,
/// The name of the group channel.
pub name: Option<String>,
/// The Id of the group owner.
pub owner_id: UserId,
/// A map of the group's recipients.
#[serde(deserialize_with="deserialize_users")]
pub recipients: HashMap<UserId, Arc<RwLock<User>>>,
}
```
This is much simpler and does not have as much boilerplate.
There should not be any backwards incompatible changes other than the
old, public - yet undocumented (and hidden from documentation) - decode
methods being removed. Due to the nature of this commit, field names may
be incorrect, and will need to be corrected as deserialization errors
are found.
|
| |
|
| |
Also the dreaded `ctx <<= "something"` which is actually a mistake.
|
| |
|
|
|
|
|
|
| |
When implemented, it was thought that images and thumbnails would be
able to have their height/width specified. This isn't the case, and so
the image/height methods were deprecated on the builders. Time has
passed, so just remove them in favour of direct methods on CreateEmbed
instead.
|
| | |
|
| |
|
|
|
|
| |
The height and width fields for embed images and thumbnails can not be
set - whereas originally there may have been plans to - so deprecate
them and remove in v0.3.0.
|
| |
|