rust-clippy icon indicating copy to clipboard operation
rust-clippy copied to clipboard

Generic async function `not_send`

Open GilRtr opened this issue 4 years ago • 3 comments
trafficstars

Lint name: future_not_send

I tried this code:

async fn recv_msg<'b, R: AsyncRead + Unpin>(
    reader: &'_ mut R,
    buf: &'b mut Vec<u8>,
) -> io::Result<&'b mut Vec<u8>> {
    let len = reader.read_u16().await? as usize;
    buf.resize_with(len, u8::default);
    let bytes_read = reader.read_exact(buf).await?;
    debug_assert_eq!(bytes_read, len);
    Ok(buf)
}

I expected to see this happen: nothing - I think this code is correct, the returned future is not Send only if R isn't.

Instead, this happened: warning - Clippy complains that the future isn't Send because reader is used across await (by drop) and reader does not implement Send

Meta

  • cargo clippy -V: 0.0.212 (cb75ad5d 2021-02-10)
  • rustc -Vv:
    rustc 1.50.0 (cb75ad5db 2021-02-10)
    binary: rustc
    commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
    commit-date: 2021-02-10
    host: x86_64-pc-windows-msvc
    release: 1.50.0
    

GilRtr avatar Mar 21 '21 21:03 GilRtr

the returned future is not Send only if R isn't

So then shouldn't you add the constraint R: Send to ensure that the future is Send?

camsteffen avatar May 03 '21 17:05 camsteffen

This is stopping this lint being used in https://github.com/serenity-rs/serenity because a lot of methods take impl Into<T>, and it would take a lot of unnecessary change to add + Send to all of these. There should at least be a setting to allow this lint not to trigger for generics.

GnomedDev avatar Jul 25 '22 13:07 GnomedDev

the returned future is not Send only if R isn't

So then shouldn't you add the constraint R: Send to ensure that the future is Send?

That means users with a runtime that doesn't require Send (i.e. single threaded runtime) can no longer use the function, for no good reason.

I believe this lint should only lint async functions whose future is unconditionally !Send. Because library authors want to verify "does my function support Send environment", not "does my function force Send environment"

I'd also be fine with a new lint future_not_send_unconditionally. As long as a lint in that form exists at all, because it would be very useful 😇

kangalio avatar Jul 25 '22 17:07 kangalio