Skip to content

drop-tracking: type parameters are incorrectly required to be Send to make futures Send #98477

Closed
@jyn514

Description

@jyn514

cc #97331, @eholk. Minimized from https://crater-reports.s3.amazonaws.com/pr-97334/try%23615edd3ad1cf6871c977dc900317cb6c2070fd6b/gh/AtsushiMiyazaki.rust-cmd/log.txt in the crater run for #97334.

I tried this code:

fn assert_send<F: Send>(_: F) {}

async fn __post<T>() -> T {
    if false {
        todo!()
    } else {
        async {}.await;
        todo!()
    }
}

fn foo<T>() {
    assert_send(__post::<T>());
}

I expected to see this happen: The code compiles fine, like it does without -Zdrop-tracking. The code doesn't actually use T anywhere so it shouldn't require it to be Send.

Instead, this happened:

error: future cannot be sent between threads safely
  --> rust-iost/rpc/src/lib.rs:13:17
   |
13 |     assert_send(__post::<T>());
   |                 ^^^^^^^^^^^^^ future returned by `__post` is not `Send`
   |
note: future is not `Send` as this value is used across an await
  --> rust-iost/rpc/src/lib.rs:7:17
   |
4  |       if false {
   |  ______________-
5  | |         todo!()
6  | |     } else {
   | |_____- has type `T` which is not `Send`
7  |           async {}.await;
   |                   ^^^^^^ await occurs here, with the value maybe used later
8  |           todo!()
9  |       }
   |       - the value is later dropped here
note: required by a bound in `assert_send`
  --> rust-iost/rpc/src/lib.rs:1:19
   |
1  | fn assert_send<F: Send>(_: F) {}
   |                   ^^^^ required by this bound in `assert_send`
help: consider restricting type parameter `T`
   |
12 | fn foo<T: std::marker::Send>() {
   |         +++++++++++++++++++

Meta

rustc --version --verbose: 615edd3ad1cf6871c977dc900317cb6c2070fd6b

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-async-awaitArea: Async & AwaitAsyncAwait-TriagedAsync-await issues that have been triaged during a working group meeting.C-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions