rust-clippy
rust-clippy copied to clipboard
Generic async function `not_send`
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
the returned future is not
Sendonly ifRisn't
So then shouldn't you add the constraint R: Send to ensure that the future is Send?
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.
the returned future is not
Sendonly ifRisn'tSo then shouldn't you add the constraint
R: Sendto ensure that the future isSend?
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 😇