Stream: wg-async-foundations

Topic: weekly meeting-ish 2019.04.02


Taylor Cramer (Apr 02 2019 at 17:00, on Zulip):

@WG-async-await o/

Taylor Cramer (Apr 02 2019 at 17:01, on Zulip):

Status updates:
- https://github.com/rust-lang/rust/pull/59286 has landed, fixes all known async fn lifetime bugs, but multiple lifetimes are still unsupported

Taylor Cramer (Apr 02 2019 at 17:02, on Zulip):

@davidtwco I saw you closed https://github.com/rust-lang/rust/pull/59135

Taylor Cramer (Apr 02 2019 at 17:03, on Zulip):

I've nominated https://github.com/rust-lang/rust/issues/54716 for discussion in the next lang mtg so we can figure out what we want.

Taylor Cramer (Apr 02 2019 at 17:04, on Zulip):

@davidtwco is https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await/topic/.2354716.20drop.20order/near/160792119 still the most up-to-date summary?

davidtwco (Apr 02 2019 at 17:04, on Zulip):

davidtwco I saw you closed https://github.com/rust-lang/rust/pull/59135

I wasn't able to resolve the type inference issues that the PR had, and wasn't super happy with the approach it took - particularly the way it mangled the HIR into shape.

I've nominated https://github.com/rust-lang/rust/issues/54716 for discussion in the next lang mtg so we can figure out what we want.

Sounds good.

davidtwco is https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await/topic/.2354716.20drop.20order/near/160792119 still the most up-to-date summary?

Yes.

Taylor Cramer (Apr 02 2019 at 17:06, on Zulip):

One thing I was thinking about that sort of bothered me was how quickly we decided to accept that the current behavior wasn't the one we wanted-- namely, the current behavior actually has some advantages in terms of how unused variables aren't captured as part of the upvars of the generator, which helps with size, and dropping them early could potentially be a performance help.

davidtwco (Apr 02 2019 at 17:06, on Zulip):

Behaviour-wise, I think the PR achieved the desired effect (not quite the exact same ordering though). The only issues I had were with the implementation.

Taylor Cramer (Apr 02 2019 at 17:07, on Zulip):

yeah, it's definitely closer to what we discussed. I'm just having thoughts :)

davidtwco (Apr 02 2019 at 17:08, on Zulip):

There are certainly benefits to the way it works just now.

Taylor Cramer (Apr 02 2019 at 17:08, on Zulip):

@tmandry has been making more progress on https://github.com/rust-lang/rust/issues/52924

Taylor Cramer (Apr 02 2019 at 17:09, on Zulip):

https://github.com/rust-lang/rust/pull/59514 is part of that work

davidtwco (Apr 02 2019 at 17:09, on Zulip):

Though, the arguments you've put forward there are mostly relating to performance rather than the user's expectations. We can put patches in place to improve the performance but if the behaviour isn't what the user expects, we can't patch that later.

Taylor Cramer (Apr 02 2019 at 17:09, on Zulip):

@tmandry looks like it's good to go w/ one final comment

Taylor Cramer (Apr 02 2019 at 17:09, on Zulip):

@davidtwco yup, but we also can't introduce optimizations that break observable behavior

davidtwco (Apr 02 2019 at 17:10, on Zulip):

I don't have an opinion either way.

Taylor Cramer (Apr 02 2019 at 17:10, on Zulip):

so the only way to get those performance improvements would be through specifying the observable behavior to be something other than the naiive expectation

Taylor Cramer (Apr 02 2019 at 17:10, on Zulip):

Yeah, I think it's a good topic to discuss in the t-lang mtg

Taylor Cramer (Apr 02 2019 at 17:13, on Zulip):

@nikomatsakis and I were supposed to figure out what to do about region inference for existential types, but I wasn't successful in sorting this out before I went on PTO last week, and he's out this week. This blocks multiple lifetimes in async fn.

Taylor Cramer (Apr 02 2019 at 17:14, on Zulip):

Aside from those (drop order, generator size, multiple lifetimes), I believe the remaining blockers are all tightly related to native syntax

Taylor Cramer (Apr 02 2019 at 17:14, on Zulip):

which is a t-lang bit to resolve.

Taylor Cramer (Apr 02 2019 at 17:15, on Zulip):

I think, unless @tmandry has anything to discuss, that's all we have at the moment.

centril (Apr 02 2019 at 17:16, on Zulip):

One bit I'd like to adjust is the order btw async and unsafe

centril (Apr 02 2019 at 17:16, on Zulip):

currently unsafe comes first

Taylor Cramer (Apr 02 2019 at 17:16, on Zulip):

@centril sure-- can you open an issue and nominate it for t-lang?

centril (Apr 02 2019 at 17:16, on Zulip):

:+1:

Taylor Cramer (Apr 02 2019 at 17:17, on Zulip):

(my expectation would be unsafe first as well, but I don't care deeply-- honestly I think it's a bit confusing that we have so many modifiers and they all have to be in a specific order in order for the parser not to tell you garbage)

tmandry (Apr 02 2019 at 17:17, on Zulip):

Nothing to discuss, really. I think we're going to end up doing #52924 the "right" way from the start in terms of layout and debuginfo, though maybe not with all enum optimizations enabled from day one

Taylor Cramer (Apr 02 2019 at 17:17, on Zulip):

I guess the "parser tells you garbage" is more of a diagnostics bug than a design issue, though

Taylor Cramer (Apr 02 2019 at 17:18, on Zulip):

@tmandry can you say what you mena about the "right" way? you mean without the "only if the places are only valid for one yield point" trick?

tmandry (Apr 02 2019 at 17:18, on Zulip):

No, it'll still just have that optimization

tmandry (Apr 02 2019 at 17:19, on Zulip):

I mean more in terms of how generators integrate with the rest of the compiler backend, and what kinds of optimizations we can enable

tmandry (Apr 02 2019 at 17:19, on Zulip):

I think the expectation is "it can act just like an enum" with all the optimizations that come with that, and we're doing the refactoring work to let us meet those expectations, eventually

tmandry (Apr 02 2019 at 17:21, on Zulip):

The code and layout that comes out should look exactly as if you hand-rolled an enum

tmandry (Apr 02 2019 at 17:21, on Zulip):

But this required some refactoring, e.g. next up is changing the field number of the discriminant, and removing the assumption that multi-variant layouts only have one field (for the discriminant) on their outer layout

tmandry (Apr 02 2019 at 17:21, on Zulip):

So we can have an "enum" (multi-variant layout) with fields that are always-valid, regardless of the value of the discriminant

tmandry (Apr 02 2019 at 17:22, on Zulip):

This should allow us to do all the UB checking that @RalfJ was talking about too (link)

tmandry (Apr 02 2019 at 17:22, on Zulip):

Rather than just treating generators as blobs of bytes

tmandry (Apr 02 2019 at 17:23, on Zulip):

Does that make sense?

Taylor Cramer (Apr 02 2019 at 17:28, on Zulip):

Yeah! that sounds much better than what I'd been imagining :)

Taylor Cramer (Apr 02 2019 at 17:29, on Zulip):

@tmandry does this also mean that we wouldn't have the single i32 (or whatever it was) tag field anymore, but do niche-filling for the tag as well?

tmandry (Apr 02 2019 at 17:29, on Zulip):

I think that should be pretty straightforward to enable

tmandry (Apr 02 2019 at 17:29, on Zulip):

But not making any promises ;)

Taylor Cramer (Apr 02 2019 at 17:30, on Zulip):

Cool, good to know.

Last update: Nov 18 2019 at 00:45UTC