@asomers I think the nightly is failing because some sort of new lints unrelated to this PR, would you like me to fix those also here?

@asomers I think the nightly is failing because some sort of new lints unrelated to this PR, would you like me to fix those also here?

It's already fixed on master. You just need to rebase.

Great! It looks like it's ready now

I think the tests could really benefit from some kind of assertion to check that they actually implement the additional trait. That might be hard to do with Send, but what about something like this?

trait Foo {}
#[automock]
#[trait_variant::make(Foo)]
pub trait Bar {
    ...
}
#[test]
fn some_test_method_name() {
    let mock = MockBar::new();
    let p: Box<dyn Foo> = Box::new(mock);   // Ensures that MockBar implements Foo
    ...
}

Also, with this change, does the #[trait_variant::make(OtherTraitName: Foo)] syntax work?

I'm not that familiar with the codebase to implement all of those changes.

On your first example, automock would not implement Foo trait for MockBar, because it might have any arbitrary number of unrelated methods, but it could be manually implemented:

trait Foo {}
#[automock]
#[trait_variant::make(Foo)]
pub trait Bar {
    ...
}
impl Foo for MockBar {}

The most common use case is to mark your trait (and async method futures) Send, and mocks are already Send so that's covered.

As for the second example, the syntax already works, but we would be mocking the initial trait only (Bar), not the other variant (OtherTraitName). With that syntax you're actually defining two different traits.

@asomers The main goal of this PR is to have feature parity with async_trait, other improvements could be added later.

As mentioend on #639 the async_trait annotation can be located before or after the automock annotation, and that means you need to return the actual pinned future or just the future's output on the mocks expectations.

With this PR we can do the same for trait_variant, so that the migration is painless.