Skip to content

Regression in async generator and fmt internals: loss of Send #93274

Closed

Description

@danielhenrymantilla

If an .await occurs inside a formatting macro, the resulting generator is no longer Send.

Context

This has already tripped up some people which seem to get quite confused with this error message, so I'd rather we not regress here:

Code

I tried this code:

async fn foo() {
    println!("{} {:?}", "", async {}.await);
}

const _ASSERT_SEND: fn() = || {
    let _: &dyn Send = &foo();
};

I expected to see this happen: Code compiles fine: the type of foo() is Send.

Instead, this happened: The type of foo() is not send, since the backing state-machine generator produced for it now captures part of the fmt internals involving a & reference to the extern { type Opaque; }, which is not Sync.

Version it worked on

It most recently worked on: beta

Version with regression

rustc --version --verbose:

nightly-2022-01-23 84322efad553c7a79c80

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

Activity

  1. added
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    and removed
    regression-untriagedUntriaged performance or correctness regression.
    on Jan 24, 2022
  2. added this to the 1.60.0 milestone on Jan 24, 2022
  3. matthiaskrgr commented on Jan 24, 2022

    @matthiaskrgr
    Member

    Might be related to #91032 / #93165 ?

  4. danielhenrymantilla commented on Jan 24, 2022

    @danielhenrymantilla
    ContributorAuthor

    @matthiaskrgr I was also suspecting one of those, although I have to admit not having looked into it any further

  5. lqd commented on Jan 25, 2022

    @lqd
    Member

    Does it work with #93284 btw ? That should completely disable drop range tracking. (I've launched a try build there so that we have artifacts ready for that soon).

    There were also recent changes in the formatting macros/machinery last week IIRC. That could be related as well.

    This should be easy enough to bisect, and make sure where the regression is coming from.

  6. lqd commented on Jan 25, 2022

    @lqd
    Member

    Answering my own questions:

  7. danielhenrymantilla commented on Jan 25, 2022

    @danielhenrymantilla
    ContributorAuthor

    Nice investigation @lqd!

  8. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Jan 27, 2022
  9. apiraino commented on Jan 27, 2022

    @apiraino
    Contributor

    Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

    @rustbot label -I-prioritize +P-high

  10. added
    P-highHigh priority
    and removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Jan 27, 2022
  11. self-assigned this
    on Jan 29, 2022
  12. added a commit that references this issue on Jan 31, 2022
    c1e2948
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-async-awaitArea: Async & AwaitC-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions