Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Context from FullEvent #2626

Merged
merged 2 commits into from
Nov 27, 2023
Merged

Conversation

GnomedDev
Copy link
Member

The macro syntax looks a bit weird as otherwise I run into parsing issues with ctx getting parsed the same as a variant name, so I had to put the pipe there as a separator. This is a general clean up as FullEvent is really weird otherwise, and makes generic Client::data a bit easier (no need for manual clone impl) if we are going to pursue that.

@github-actions github-actions bot added framework Related to the `framework` and `framework::standard` modules and/or the `command_attr` crate client Related to the `client` module. gateway Related to the `gateway` module. labels Nov 25, 2023
@@ -14,17 +14,17 @@ macro_rules! event_handler {
( $(
$( #[doc = $doc:literal] )*
$( #[cfg(feature = $feature:literal)] )?
async fn $method_name:ident(&self, $variant_name:ident { $(
async fn $method_name:ident(&self, $($context:ident: Context,)? | $variant_name:ident { $(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will get to full review later, but why is this | here? Shouldn't the matching work fine without it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, apparently not, since both $context and $variant_name are identifiers, the parsing becomes ambiguous. This could still be done without the bar by defining a event_handler_method! macro that generates one method at a time and is called inside event_handler! for each method. It could have a second rule that takes a special @NO-CONTEXT token at the start which then wouldn't generate a ctx: Context parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the best at macro_rules syntax, I'd prefer if this somewhat janky syntax is kept for now and a followup PR could correct it if possible.

Comment on lines +95 to +98
fn update_cache_with_event(
#[cfg(feature = "cache")] cache: &Cache,
event: Event,
) -> Option<(FullEvent, Option<FullEvent>)> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of the macro invocations here end up using the cache unconditionally, which I guess somehow works, but it still feels weird to pass in an undefined identifier if the cache is disabled.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's overall a bad situation, but I don't think passing Context is any better, because it's still an undefined field access in that case.

Copy link
Collaborator

@mkrasnitski mkrasnitski Nov 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't you just inline the macro invocations and feature-flag them? Btw, I noticed there's calls to if_cache!(event.update(cache)) which are almost equivalent to just update_cache!(cache, event).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if_cache!(event.update(cache)) returns None if cache is disabled, whereas update_cache!(cache, event) returns (). This difference is needed because otherwise the None would need to be qualified for it's T. I could of course inline the macro invocations, but that would get very repetitive very quickly and make it a lot harder to read.

src/client/dispatch.rs Show resolved Hide resolved
src/gateway/bridge/shard_runner.rs Show resolved Hide resolved
src/client/event_handler.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@mkrasnitski mkrasnitski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remaining things are purely internal and can be fixed in a followup PR. LGTM

@arqunis arqunis added enhancement An improvement to Serenity. breaking change The public API is changed, resulting in miscompilations or unexpected new behaviour for users labels Nov 27, 2023
@arqunis arqunis merged commit 2259658 into serenity-rs:current Nov 27, 2023
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change The public API is changed, resulting in miscompilations or unexpected new behaviour for users client Related to the `client` module. enhancement An improvement to Serenity. framework Related to the `framework` and `framework::standard` modules and/or the `command_attr` crate gateway Related to the `gateway` module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants