Skip to content

fix(macros): Allow #[tool] to work even if Future is not in scope #385

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(macros): Allow #[tool] to work even if Future is not in scope #385

wants to merge 1 commit into from
+5 −5

Conversation

swlynch99
Copy link

@swlynch99 swlynch99 commented Aug 20, 2025 •
edited
Loading

This changes the expansion of #[tool] to emit std::future::Future instead of Future.

Motivation and Context

This is a pretty small papercut, but if you use #[tool] on an async function then it requires that Future be imported.

How Has This Been Tested?

cargo check --all-targets passes

Breaking Changes

No

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@github-actions github-actions bot added the T-macros Macro changes label Aug 20, 2025
@4t145
Copy link
Collaborator

4t145 commented Aug 21, 2025

The current MSRV is 1.85.1, so I think by default Future is supposed to be in the scope?

@swlynch99 swlynch99 force-pushed the dont-require-future-in-scope branch from e6670e2 to e701044 Compare August 21, 2025 18:26
@swlynch99
Copy link
Author

As far I can tell that only applies to the 2024 edition. Previous editions do not have Future in the prelude.

Anyway it seems like #351 changed this to use futures::BoxFuture. Unfortunately that is still wrong. Now you're requiring that downstream crates have futures available locally.

@4t145
Copy link
Collaborator

4t145 commented Aug 22, 2025 •
edited
Loading

As far I can tell that only applies to the 2024 edition. Previous editions do not have Future in the prelude.

I am not saying to reject to support 2021 edition, just wondering in what case you have to use 2021 edtion instead 2024 edition. There was a developer also requested the compatibility for the 2021 edition, it's because he is still using windows 7.

Anyway it seems like #351 changed this to use futures::BoxFuture. Unfortunately that is still wrong.

You are right, I missed this when review code.

4t145
4t145 previously approved these changes Aug 22, 2025
View reviewed changes
@4t145
Copy link
Collaborator

4t145 commented Aug 22, 2025 •
edited
Loading

It should have the same problem in the newly merged prompt macro's code, could you fix it together in this PR?

@swlynch99 swlynch99 force-pushed the dont-require-future-in-scope branch from e701044 to f441670 Compare August 22, 2025 19:39
@swlynch99 swlynch99 changed the title Allow #[tool] to work even if Future is not in scope fix(macros): Allow #[tool] to work even if Future is not in scope Aug 22, 2025
@swlynch99
fix(macros): Allow macros to work even if Future is not in scope
1f34864 
`#[tool]` generates code that uses Future by name for async functions.
This means that consumers have to import Future. This commit fixes that
by changing the macro expansion to use std::future::Future instead.

The same applies to `#[prompt]` as well.
@swlynch99 swlynch99 force-pushed the dont-require-future-in-scope branch from f441670 to 1f34864 Compare August 22, 2025 19:43
@swlynch99
Copy link
Author

I am not saying to reject to support 2021 edition, just wondering in what case you have to use 2021 edtion instead 2024 edition. There was a developer also requested the compatibility for the 2021 edition, it's because he is still using windows 7.

The features added in the 2024 edition are small enough that actually doing the upgrade is just low on my priority list. It's not an MSRV constraint, I am still using the latest stable rustc with edition 2021.

It should have the same problem in the newly merged prompt macro's code, could you fix it together in this PR?

I have updated the prompt macro impl to match. Everything should be good to go now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@4t145 4t145 4t145 left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
T-macros Macro changes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@swlynch99 @4t145