Regression in async generator and fmt internals: loss of Send

[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:

• https://users.rust-lang.org/t/future-created-by-async-block-is-not-send/70796/3?u=yandros

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

[matthiaskrgr]

Might be related to #91032 / #93165 ?

[danielhenrymantilla]

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

[lqd]

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.

[lqd]

Answering my own questions:

• Disable drop range analysis #93284 doesn't change this, my guess is that it's actually unrelated to Introduce drop range tracking to generator interior analysis #91032
• Introduce drop range tracking to generator interior analysis #91032 initially landed as part of Rollup of 17 pull requests #93138 and that rollup's commit 523be2e05da322daaecf1ecc8f2c0d625f5f46e3 doesn't reproduce the issue
• the format_args change I mentioned was Emit simpler code from format_args #91359 and its commit 0bcacb391b28460f5a50fd627f01f670dfcfc7cc does reproduce the issue. This PR seems to have caused it indeed.

[danielhenrymantilla]

Nice investigation @lqd!

[apiraino]

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

@rustbot label -I-prioritize +P-high