-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-async-awaitArea: Async & AwaitArea: Async & AwaitC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Here's the smallest example I could come up with, extracted from the larger project I was working on:
use std::future::Future;
use std::sync::RwLock;
pub async fn f(lock: RwLock<()>) {
let guard = lock.read().unwrap();
let () = *guard;
drop(guard);
wait().await;
}
pub async fn g(lock: RwLock<()>) {
{
let guard = lock.read().unwrap();
let () = *guard;
}
wait().await;
}
pub async fn wait() {}
pub fn require_send(_fut: impl Future + Send) {}
pub fn check() {
require_send(f(RwLock::new(())));
require_send(g(RwLock::new(())));
}
I expected to see this happen: Both f
and g
should be equivalent, I think. The only difference between them is whether guard
becomes dead at the end of a block or at the call to drop
. In both cases, I believe it should be dead before the await
.
Instead, this happened: g
compiles without error, but attempting to use f
reports "error: future cannot be sent between threads safely", because "future is not Send
as [guard
] is used across an await".
Meta
rustc --version --verbose
:
rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5
Using the Rust playground, I've also checked 1.89.0-beta.6 (2025-07-21 20c571f) and 1.90.0-nightly (2025-07-23 ace6330).
Metadata
Metadata
Assignees
Labels
A-async-awaitArea: Async & AwaitArea: Async & AwaitC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.