Option to bypass generating Send when mocking async functions

[OscarTHZhang]

Currently when passing #[automock] to a trait with async functions, it automatically generates Send for its return value to ensure thread safety. However, I am working on an async runtime that guarantees to be run on a single thread, so it does not require Send for its return value.

I'd like to request a feature to add a flag in #[automock] or something similar to not generate Send for mocked functions' return value.

[asomers]

Are there any cases where the Send impl causes problems? Could you please provide an example?

[insipx]

Send can become a problem in webassembly environments, where futures may not be send

async-trait solves this by adding a ?Send attribute: https://docs.rs/async-trait/latest/async_trait/#non-threadsafe-futures

So then the annotation becomes

#[cfg_attr(target_arch = "wasm32", async_trait(?Send))]
#[cfg_attr(not(target_arch = "wasm32"), async_trait)]

Personally I haven't ran into this, I think using Mock avoids this problem. Although there's a separate unrelated issue where you can't use cfg_attr, which requires two cfged blocks anyway:

https://github.com/xmtp/libxmtp/blob/cf10e9cd85ec43979fb5b42d3962034abe060333/xmtp_api/src/test_utils.rs#L120

[asomers]

But what problem does it cause? A Future that is Send but doesn't need to be should be acceptable by any function that takes a non-Send Future as its argument, right?