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

chore: Remove async-trait #5812

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

kayabaNerve
Copy link
Contributor

@kayabaNerve kayabaNerve commented Jan 13, 2025

Description

Removes async-trait for usage of RPIT.

Notes & open questions

libp2p's MSRV has included RPIT for a while now, making this possible. The Send bounds follow the behavior from async-trait. async-trait's generation of Pin<Box<dyn Future>> also provided Unpin which has not been a preserved bound EXCEPT in the test code which required it in in-tree call sites. Moving forward, callers expecting Unpin should wrap their futures themselves with Box::pin.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

libp2p's MSRV has included RPIT for a while now, making this possible. The
`Send` bounds follow the behavior from async-trait. async-trait's generation of
`Pin<Box<dyn Future>>` also provided `Unpin` which has *not* been a preserved
bound EXCEPT in the test code which required it in in-tree call sites. Moving
forward, callers expecting `Unpin` should wrap their futures themselves with
`Box::pin`.
@kayabaNerve
Copy link
Contributor Author

kayabaNerve commented Jan 13, 2025

libp2p-request-response already has an unpublished breaking change release in-tree. Most of the modified crates solely had their libp2p-request-response integrations edited, and already had a CHANGELOG entry for their update to the latest version.

libp2p-dns is weird. It has a hidden, public API item I did make breaking changes to and did not already have an unpublished breaking change in release (solely a patch release). It doesn't need a breaking change release if the hidden API entry is considered NOT part of the public API. I assumed that yes, there would be issues to change it without a new release however (as it has no in-tree users so it presumably services out-of-tree crates), and did bump the minor version. If these changes are an area of contest, they can be moved to a distinct PR as the libp2p-request-response changes are my priority.

No documentation/tests were needed for this, hence the unchecked boxes in the checklist.

It'd be great to have this included prior to the new releases which are about to occur. Sorry if it's too last minute.

@kayabaNerve kayabaNerve changed the title Remove async-trait chore: Remove async-trait Jan 13, 2025
@elenaf9
Copy link
Contributor

elenaf9 commented Jan 14, 2025

Hi @kayabaNerve, thank you for the PR!

Could you share a bit about the motivation for removing the use of async-trait?

It'd be great to have this included prior to the new releases which are about to occur. Sorry if it's too last minute.

We are planning to release today, so unfortunately it's a bit too short notice. If it's very urgent we could cut another release soon-ish, but it be great to know why.

@kayabaNerve
Copy link
Contributor Author

It's an unnecessary dependency with worse codegen? It only existed because RPIT wasn't stable and RPIT has been stable for months now. libp2p's MSRV includes RPIT as well, so there really is no blocker.

Copy link
Member

@dariusc93 dariusc93 left a comment

Choose a reason for hiding this comment

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

Looks like a good start imho. Left some comments though

&mut self,
_: &StreamProtocol,
io: &mut T,
) -> impl Send + Future<Output = io::Result<Self::Request>>
Copy link
Member

Choose a reason for hiding this comment

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

nit: it might be better to have Send last

Copy link
Member

Choose a reason for hiding this comment

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

Additionally, we could probably leave the async signature intact here while having the trait member return impl Future<Output = T> + Send without a compiler warning. Thoughts on that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I left a comment misunderstanding your note which I've now deleted.

async fn for the implementations should be possible 👍 TIL.

Copy link
Contributor

mergify bot commented Jan 22, 2025

This pull request has merge conflicts. Could you please resolve them @kayabaNerve? 🙏

@dariusc93
Copy link
Member

Could you share a bit about the motivation for removing the use of async-trait?

Would be one less dependency we would be using, and allow us to begin to adapt RPIT where possible.

It's an unnecessary dependency with worse codegen? It only existed because RPIT wasn't stable and RPIT has been stable for months now. libp2p's MSRV includes RPIT as well, so there really is no blocker.

Are we losing anything by removing async-trait that would be beneficial to rust-libp2p? I dont believe we are utilizing dynamic dispatch with async-trait (since it is not object safe right now for a trait member to utilize async signature or impl Trait to my knowledge) so that shouldnt be a problem. It would reduce some of the additional codegen, although I dont think the impact would be that much if we were to leave async-trait in place

@kayabaNerve
Copy link
Contributor Author

kayabaNerve commented Jan 23, 2025

The codegen arguments are definitely marginal. I don't expect this will be 10% on any benchmarks, or even 1%. Maybe a fraction of a percent on some benchmarks as I believe this does avoid a vtable lookup?

But the argument for this is to be in modern style, and for fine control of the exact bounds on returned futures.

I don't personally see anything lost but I do dread to hear this could be released and suddenly a non-trivial amount of downstream consumers do have to add glue to update (Box::pin calls on every returned future, for example). I don't expect that to be the case at all, I'm just deferring confirmation this won't be an issue to someone else.

@kayabaNerve
Copy link
Contributor Author

kayabaNerve commented Jan 23, 2025

trait-variant was supposed to be extended with support for dynamic dispatch over such traits. It wasn't and appears to be low priority/unmaintained.

https://github.com/spastorino/dynosaur does exist and would allow anyone who needs dynamic dispatch to continue their usage of it, but the actual derivation may need to be within libp2p... I'd advocate dropping support for dynamic dispatch or closing this PR before suggesting adopting a distinct shim crate at this level.

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.

3 participants