Skip to content

Conversation

@Sclock
Copy link
Contributor

@Sclock Sclock commented Dec 8, 2025

Background

Pumpkin’s Plugin trait requires plugin methods (e.g., on_load) to return:

Pin<Box<dyn Future<Output = Result<(), String>> + Send>>

However, the current implementation of the #[plugin_method] macro rewrites methods into an async fn, which compiles into:

impl Future<Output = Result<(), String>>

This causes a type mismatch when implementing the Plugin trait, resulting in compilation error E0053.

❗ Problem

When using:

#[plugin_method]
async fn on_load(...) -> Result<(), String> { ... }

the generated method has signature:

fn on_load(...) -> impl Future<...>

but the trait expects:

fn on_load(...) -> Pin<Box<dyn Future<...> + Send>>

This mismatch triggers:

error[E0053]: method on_load has an incompatible type for trait

✅ Solution

Modify the plugin_method macro to wrap the async block into a boxed future, producing the correct return type expected by the Plugin trait.

Key Changes

Replace the generated async fn with a regular fn returning:

Pin<Box<dyn Future<Output = Result<(), String>> + Send>>

Wrap the original async body using:

Box::pin(async move {
    crate::GLOBAL_RUNTIME.block_on(async move { ... })
})

Preserve the user-written method body while ensuring type compatibility.

📄 Summary of Changes

Updated the expansion of #[plugin_method] to generate a boxed future instead of impl Future.

Ensured all plugin methods rewritten by the macro now fully satisfy the Pumpkin Plugin trait signatures.

No changes required from plugin authors—existing macro usage continues to work.

🔍 Impact

Fixes compilation failure for any method tagged with #[plugin_method].

Makes macro behavior trait-compliant.

No breaking API changes.

@Sclock
Copy link
Contributor Author

Sclock commented Dec 8, 2025

After testing, it can only solve the compilation problem, but it will get stuck during operation

2025-12-08 17:52:33 [INFO] (57) schedule thread start id: ThreadId(57) name: Schedule Thread
2025-12-08 17:52:33 [INFO] (1) Query protocol is enabled. Starting...
2025-12-08 17:52:33 [INFO] (6) Server query running on port 25565

@Snowiiii
Copy link
Member

Snowiiii commented Dec 8, 2025

After testing, it can only solve the compilation problem, but it will get stuck during operation

2025-12-08 17:52:33 [INFO] (57) schedule thread start id: ThreadId(57) name: Schedule Thread 2025-12-08 17:52:33 [INFO] (1) Query protocol is enabled. Starting... 2025-12-08 17:52:33 [INFO] (6) Server query running on port 25565

Any ideas why?, Would be great to have that fixed before merging

crate::GLOBAL_RUNTIME.block_on(async move {
#fn_body
fn #fn_name(#fn_inputs) -> std::pin::Pin<
Box<dyn std::future::Future<Output = Result<(), String>> + Send>
Copy link
Contributor

Choose a reason for hiding this comment

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

While it is true that all current plugin methods return a Result<(), String>, this may not be the case in the future. I'd personally prefer if the input function's return type was taken into account when generating the final function.

@Sclock
Copy link
Contributor Author

Sclock commented Dec 8, 2025

After testing, it can only solve the compilation problem, but it will get stuck during operation
2025-12-08 17:52:33 [INFO] (57) schedule thread start id: ThreadId(57) name: Schedule Thread 2025-12-08 17:52:33 [INFO] (1) Query protocol is enabled. Starting... 2025-12-08 17:52:33 [INFO] (6) Server query running on port 25565

Any ideas why?, Would be great to have that fixed before merging

I'm sorry, my abilities are limited. Let's first address the issue with plugin_method

@Sclock
Copy link
Contributor Author

Sclock commented Dec 8, 2025

After testing, it can only solve the compilation problem, but it will get stuck during operation
2025-12-08 17:52:33 [INFO] (57) schedule thread start id: ThreadId(57) name: Schedule Thread 2025-12-08 17:52:33 [INFO] (1) Query protocol is enabled. Starting... 2025-12-08 17:52:33 [INFO] (6) Server query running on port 25565

Any ideas why?, Would be great to have that fixed before merging

I have checked it and it seems that the problem is with on_load

@Sclock
Copy link
Contributor Author

Sclock commented Dec 8, 2025

The reason is the deadlock caused by pumpkin::init_log!();. Removing the log initialization in the plugin will prevent the failure to start

@BjornTheProgrammer
Copy link
Contributor

I've done my own investigation into this as well. Since dynamically included librarys have a different address space, the logger never is able to use the already defined logger in the pumpkin main process. Instead it must create its own first, but that is never done, so it just waits, this was exposed in #1201.

The best way to fix this might be to remove the macro entirely, and to add the logger to the context instead. I'm working on that in my PR #1241

@Snowiiii
Copy link
Member

fixed in #1241

@Snowiiii Snowiiii closed this Jan 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants