- Notifications
You must be signed in to change notification settings - Fork 13.9k
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.