Stream: wg-async-foundations

Topic: meeting 2019.09.24


nikomatsakis (Sep 24 2019 at 16:30, on Zulip):

Hey all -- I might be a bit late today fyi

Taylor Cramer (Sep 24 2019 at 16:34, on Zulip):

:thumbs_up:

nikomatsakis (Sep 24 2019 at 17:05, on Zulip):

Hey @WG-async-foundations -- I'll be back in ~5 minutes -- but if somebody else wants to get started, seems good. We are basically on path to stabilization now. I'd say first sweep for priority issues but it'd also be good for us to discuss how to go forward.

Taylor Cramer (Sep 24 2019 at 17:08, on Zulip):

we've got a handful of open issues tagged with "unclear", so let's try and clean those up:
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AAsyncAwait-Unclear

Giles Cope (Sep 24 2019 at 17:08, on Zulip):

I'm still chewing the fat on #64603 looking at @Matthew Jasper suggestion. Haven't quite got a fresh PR that passes all the tests yet.

Taylor Cramer (Sep 24 2019 at 17:09, on Zulip):

https://github.com/rust-lang/rust/issues/64692 seems a bit concerning-- we're missing a private-in-public error for async fn return types

Taylor Cramer (Sep 24 2019 at 17:10, on Zulip):

Actually, it does give the error, but only as a future-compat warning

Taylor Cramer (Sep 24 2019 at 17:11, on Zulip):

that seems like not a big deal to me-- it seems somewhat unlikely that users will be writing lots of new code and leaving it as-is when given a future-compat warning.

Taylor Cramer (Sep 24 2019 at 17:11, on Zulip):

what do others think?

Giles Cope (Sep 24 2019 at 17:12, on Zulip):

be nice to turn it into a hard error if inside async func I guess?

Taylor Cramer (Sep 24 2019 at 17:12, on Zulip):

indeed, but I don't think it's blocking.

Giles Cope (Sep 24 2019 at 17:12, on Zulip):

agreed

Taylor Cramer (Sep 24 2019 at 17:13, on Zulip):

Okay, next one is https://github.com/rust-lang/rust/issues/64630

centril (Sep 24 2019 at 17:13, on Zulip):

matthew is assigned

centril (Sep 24 2019 at 17:14, on Zulip):

maybe backport if small-ish

Taylor Cramer (Sep 24 2019 at 17:14, on Zulip):

this is happening because the desugaring of async fn uses the '_ lifetime. Good to know @Matthew Jasper is assigned, but I also don't think this is a blocker.

Taylor Cramer (Sep 24 2019 at 17:14, on Zulip):

Okay, I'll leave a comment and switch the label.

Taylor Cramer (Sep 24 2019 at 17:16, on Zulip):

https://github.com/rust-lang/rust/issues/64552

Taylor Cramer (Sep 24 2019 at 17:16, on Zulip):

"Lifetime bounds in auto trait impls prevent trait from being implemented on generators"

Giles Cope (Sep 24 2019 at 17:17, on Zulip):

I can't say I'd be happy to get #64552's error message though I'm not sure how it could be made nicer...

Taylor Cramer (Sep 24 2019 at 17:17, on Zulip):

I mean, the real issue is that it causes an error at all, right?

Taylor Cramer (Sep 24 2019 at 17:18, on Zulip):

@Aaron Hill did some good investigation and wrote up implementation steps here: https://github.com/rust-lang/rust/issues/64552#issuecomment-533335959

Taylor Cramer (Sep 24 2019 at 17:19, on Zulip):

I don't have a good sense for whether or not this is a backcompat hazard-- perhaps @nikomatsakis can comment?

Taylor Cramer (Sep 24 2019 at 17:21, on Zulip):

Okay, let's move on and come back to it when @nikomatsakis is around.

Taylor Cramer (Sep 24 2019 at 17:21, on Zulip):

https://github.com/rust-lang/rust/issues/64433 I think we can close as fixed.

nikomatsakis (Sep 24 2019 at 17:21, on Zulip):

(I'm back now)

nikomatsakis (Sep 24 2019 at 17:21, on Zulip):

sorry

Taylor Cramer (Sep 24 2019 at 17:21, on Zulip):

oh hai

Taylor Cramer (Sep 24 2019 at 17:22, on Zulip):

@nikomatsakis have you looked at https://github.com/rust-lang/rust/issues/64552 at all?

nikomatsakis (Sep 24 2019 at 17:22, on Zulip):

Aaron Hill did some good investigation and wrote up implementation steps here: https://github.com/rust-lang/rust/issues/64552#issuecomment-533335959

I saw @Aaron Hill's comment, but I didn't process it deeply yet. Let me go look. I didn't realize that there was a back-compat question at play here.

Taylor Cramer (Sep 24 2019 at 17:22, on Zulip):

@nikomatsakis I don't think there is, but I wanted to make sure before we tagged as "deferred"

Taylor Cramer (Sep 24 2019 at 17:23, on Zulip):

and I didn't have enough confidence in my understanding of the bug as it exists today to say that it wouldn't cause bad interactions (though I can't imagine what they would be)

nikomatsakis (Sep 24 2019 at 17:23, on Zulip):

OK, yeah, this is tied in with the work around universes

Aaron Hill (Sep 24 2019 at 17:23, on Zulip):

I don't think there is. My change should only be able to make more auto-trait impls apply to generator types. You can't name a generator type, so I don't think there's any way for users to rely on it "not* implementing an autontrait

Taylor Cramer (Sep 24 2019 at 17:24, on Zulip):

Okay, I'll tag as deferred then unless anyone objects.

nikomatsakis (Sep 24 2019 at 17:24, on Zulip):

So @Taylor Cramer I think we can defer it, but I also think we should sort of "transfer" the concern to #wg-traits (which I am slowly attempting to revive)

nikomatsakis (Sep 24 2019 at 17:24, on Zulip):

For now that probably just means me putting it on my list :)

Taylor Cramer (Sep 24 2019 at 17:25, on Zulip):

Great, I've added the WG-compiler-traits label

Taylor Cramer (Sep 24 2019 at 17:25, on Zulip):

hokay: https://github.com/rust-lang/rust/issues/64382

Aaron Hill (Sep 24 2019 at 17:25, on Zulip):

I don't think there's a back-compat hazard , specifically

Aaron Hill (Sep 24 2019 at 17:25, on Zulip):

I don't think there's a back-compat hazard , specifically

Aaron Hill (Sep 24 2019 at 17:25, on Zulip):

E.g the weird trick I do in pin-project won't work, since it relies on naming the type you're checking

nikomatsakis (Sep 24 2019 at 17:26, on Zulip):

hokay: https://github.com/rust-lang/rust/issues/64382

so this is basically a diagnostics fail, right?

Taylor Cramer (Sep 24 2019 at 17:26, on Zulip):

This is a diagnostics issue-- seems unfortunate, but not blocking.

Taylor Cramer (Sep 24 2019 at 17:27, on Zulip):

it also seems like we could suggest using an async move block

Taylor Cramer (Sep 24 2019 at 17:27, on Zulip):

similar to what we do for closures

nikomatsakis (Sep 24 2019 at 17:27, on Zulip):

yeah I was just going to say

nikomatsakis (Sep 24 2019 at 17:28, on Zulip):

maybe we can adapt that closure error message here

Taylor Cramer (Sep 24 2019 at 17:28, on Zulip):

Cool, left a comment and tagged as deferred.

Taylor Cramer (Sep 24 2019 at 17:28, on Zulip):

next up: https://github.com/rust-lang/rust/issues/64176

nikomatsakis (Sep 24 2019 at 17:29, on Zulip):

maybe related to https://github.com/rust-lang/rust/issues/64552

Taylor Cramer (Sep 24 2019 at 17:30, on Zulip):

I was gonna say that, but then the comment below reproduces without lifetimes-- though there are trait objects, which makes me suspicious that I'm missing an implied lifetime somewhere

Taylor Cramer (Sep 24 2019 at 17:31, on Zulip):

In any case, not blocking

Taylor Cramer (Sep 24 2019 at 17:32, on Zulip):

https://github.com/rust-lang/rust/issues/63710 is tagged as blocking, but will be closed when https://github.com/rust-lang/rust/pull/64599 lands. It's beta-nominated, so that should be fine.

Taylor Cramer (Sep 24 2019 at 17:33, on Zulip):

Hokay, that's the end of the unclear list

Taylor Cramer (Sep 24 2019 at 17:33, on Zulip):

blocking: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AAsyncAwait-Blocking

nikomatsakis (Sep 24 2019 at 17:34, on Zulip):

Spurious new Send requirement in async block #64477

nikomatsakis (Sep 24 2019 at 17:34, on Zulip):

So, the format! case still errors, but I didn't expect otherwise

nikomatsakis (Sep 24 2019 at 17:34, on Zulip):

I haven't however looked closely at what's going on there

nikomatsakis (Sep 24 2019 at 17:35, on Zulip):

There may be a targeted way to fix it; or it may indeed just be correct

nikomatsakis (Sep 24 2019 at 17:36, on Zulip):

(The playground doesn't have a way to view the "expanded HIR", right?)

nikomatsakis (Sep 24 2019 at 17:36, on Zulip):

in any case I think we don't have to take immediate action here

Taylor Cramer (Sep 24 2019 at 17:37, on Zulip):

I guess the only blocking decision point here would be if we decided we wanted to change our minds and not store temporaries across .await, right?

nikomatsakis (Sep 24 2019 at 17:37, on Zulip):

Though I do think I would nominate the "overapproximated Send" as a plausible "high priority fix candidate". I was thinking recently that perhaps @Zoxc was right and we can handle this just by building the MIR when we need to -- but that's probably worth resurrecting as an issue.

nikomatsakis (Sep 24 2019 at 17:37, on Zulip):

I guess the only blocking decision point here would be if we decided we wanted to change our minds and not store temporaries across .await, right?

Right. And I think we don't.

nikomatsakis (Sep 24 2019 at 17:37, on Zulip):

Otherwise, it's either a bug that we can fix, or it's just legit.

centril (Sep 24 2019 at 17:37, on Zulip):

way, way too late :P

nikomatsakis (Sep 24 2019 at 17:37, on Zulip):

But let me try to double check :)

Taylor Cramer (Sep 24 2019 at 17:37, on Zulip):

^^yup, I agree, just confirming

nikomatsakis (Sep 24 2019 at 17:39, on Zulip):

(unfortunately I think the errors are just legit, will comment -- I think I'll close the issue at that point)

Taylor Cramer (Sep 24 2019 at 17:39, on Zulip):

sg, though that's really too bad

Taylor Cramer (Sep 24 2019 at 17:39, on Zulip):

I kind of wonder whether that kind of thing will hinder the "just add .await everywhere" more than the temporary lifetimes changing

nikomatsakis (Sep 24 2019 at 17:40, on Zulip):

I think the shorter-term fix would be to tweak the format desugaring to try and make its dyn values send

Taylor Cramer (Sep 24 2019 at 17:40, on Zulip):

but, like @centril said, way too late and there are workarounds either way.

nikomatsakis (Sep 24 2019 at 17:40, on Zulip):

I kind of wonder whether that kind of thing will hinder the "just add .await everywhere" more than the temporary lifetimes changing

yeah idk but I think long term it's the right call :)

centril (Sep 24 2019 at 17:41, on Zulip):

(Re. a different issue, I might try the "insert coercion hack" in HIR lowering for async fn to see if theBox<dyn ...>problem goes away)

Taylor Cramer (Sep 24 2019 at 17:41, on Zulip):

okay then that just leaves https://github.com/rust-lang/rust/issues/64130 as the only one we haven't discussed

Taylor Cramer (Sep 24 2019 at 17:42, on Zulip):

I know @davidtwco has been working on that here: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/future-not-send.20diagnostic.20.2364130

nikomatsakis (Sep 24 2019 at 17:42, on Zulip):

@davidtwco is working on it

davidtwco (Sep 24 2019 at 17:42, on Zulip):

:+1:

Taylor Cramer (Sep 24 2019 at 17:42, on Zulip):

Is that something we're planning to backport?

nikomatsakis (Sep 24 2019 at 17:42, on Zulip):

I guess one question that I'd like to ask is people's take on backporting for things like this

davidtwco (Sep 24 2019 at 17:42, on Zulip):

Will continue tonight. Hopefully have something useful soon.

nikomatsakis (Sep 24 2019 at 17:42, on Zulip):

(jynx)

centril (Sep 24 2019 at 17:43, on Zulip):

I think it depends on the PR size and confidence

nikomatsakis (Sep 24 2019 at 17:43, on Zulip):

My take is: if it comes soon, and lands on nightly for a bit happily, and it's not overly intrusive, I'd be game to backport this one

nikomatsakis (Sep 24 2019 at 17:43, on Zulip):

Though it's not the kind of thing I would ordinarily backport

Taylor Cramer (Sep 24 2019 at 17:43, on Zulip):

Okay. Should I tag as deferred then, given that I don't think we'll lose track of it?

nikomatsakis (Sep 24 2019 at 17:43, on Zulip):

(But I view this as something of a special case)

nikomatsakis (Sep 24 2019 at 17:43, on Zulip):

yeah I think that's fine

Taylor Cramer (Sep 24 2019 at 17:43, on Zulip):

and that I don't think we actually want to stop stabilization for this?

nikomatsakis (Sep 24 2019 at 17:43, on Zulip):

I've just been using blocking as "things we're working on"

centril (Sep 24 2019 at 17:43, on Zulip):

it's forward compat, right?

nikomatsakis (Sep 24 2019 at 17:43, on Zulip):

it's just a diagnostics change

Taylor Cramer (Sep 24 2019 at 17:44, on Zulip):

Yes, just improved diagnostics

centril (Sep 24 2019 at 17:44, on Zulip):

then not a blocker

Taylor Cramer (Sep 24 2019 at 17:44, on Zulip):

well, "just"-- it's a massive improvement

nikomatsakis (Sep 24 2019 at 17:44, on Zulip):

We can discuss how we manage priority going forward, but I think I'd like to propose we rename AsyncAwait-Blocking to AsyncAwait-High

nikomatsakis (Sep 24 2019 at 17:44, on Zulip):

or perhaps -Focus

centril (Sep 24 2019 at 17:44, on Zulip):

-High/Medium/Low seems good

Taylor Cramer (Sep 24 2019 at 17:44, on Zulip):

After stabilization, I think that makes sense

centril (Sep 24 2019 at 17:45, on Zulip):

@Taylor Cramer by after do you mean next week? :P

Taylor Cramer (Sep 24 2019 at 17:45, on Zulip):

before stabilization I think it was useful to know which things we absolutely had to land-- chiefly backcompat hazards

Taylor Cramer (Sep 24 2019 at 17:45, on Zulip):

^^ yup

nikomatsakis (Sep 24 2019 at 17:45, on Zulip):

I guess it comes a bit to the question of how we're going to manage the group overall, but I think there's still a lot of "improved quality" work to be done, so i'd like us to try and keep a "slow, steady" progress thing going on

nikomatsakis (Sep 24 2019 at 17:46, on Zulip):

My basic view would be that, at any given time, we nominate ~2 or 3 issues as "high" -- those are the ones that (a) seem most urgent to us and (b) are actionable in a reasonable time frame, and we try to get them assigned. We can do more if we have more capacity, but that's also ok. If something has stayed high but made no progress for a week or two, we swap in something else. :)

nikomatsakis (Sep 24 2019 at 17:46, on Zulip):

Something like that

centril (Sep 24 2019 at 17:46, on Zulip):

Agreed; I think finishing the existing open issues should be a prio before any new feature work

Taylor Cramer (Sep 24 2019 at 17:46, on Zulip):

yeah, I'll keep posting PRs and cc'ing you or asking questions here if I have plans to do something. Nominating issues makes sense, but I don't know that a weekly check-in is super necessary.

nikomatsakis (Sep 24 2019 at 17:46, on Zulip):

(As I wrote earlier, I have blocked out a few hours of my own time per week, so I plan to try and tackle one issue per week also)

centril (Sep 24 2019 at 17:46, on Zulip):

We need a new nomination label heh

nikomatsakis (Sep 24 2019 at 17:46, on Zulip):

Hmm. I think a weekly check-in is kind of useful.

centril (Sep 24 2019 at 17:47, on Zulip):

I-nominated would be too overloaded

nikomatsakis (Sep 24 2019 at 17:47, on Zulip):

Well, maybe it's overkill, we just need some way to monitor things

Taylor Cramer (Sep 24 2019 at 17:47, on Zulip):

@nikomatsakis okay, I guess I'm a bit confused then

centril (Sep 24 2019 at 17:47, on Zulip):

Possibly bi-weekly if not weekly

Taylor Cramer (Sep 24 2019 at 17:47, on Zulip):

I'm fine keeping the weekly meeting if others are planning to come

Taylor Cramer (Sep 24 2019 at 17:47, on Zulip):

If you think it's helpful, I'd be happy to continue doing it.

nikomatsakis (Sep 24 2019 at 17:47, on Zulip):

I would imagine the goal would be :

- check to see things are making progress
- consider what new things to nominate if stuff has landed

centril (Sep 24 2019 at 17:48, on Zulip):

I imagine the weekly checkins as "access to Niko-advice-on-compiler time" :P

nikomatsakis (Sep 24 2019 at 17:48, on Zulip):

I guess maybe if we find those things are working async that's ok too

nikomatsakis (Sep 24 2019 at 17:48, on Zulip):

ok well to start shall we rename the labels ?

centril (Sep 24 2019 at 17:48, on Zulip):

yes, let's

Taylor Cramer (Sep 24 2019 at 17:48, on Zulip):

oh whoops

Taylor Cramer (Sep 24 2019 at 17:48, on Zulip):

I got myself all mixed up, sorry

nikomatsakis (Sep 24 2019 at 17:49, on Zulip):

@centril which is the issue about return coercion? if you want to put it as "-high" I'm game; I'd also be able to spend some time investigating tomorrow morning I think, though I'm happy to help mentor you through it if we find a good path

centril (Sep 24 2019 at 17:49, on Zulip):

-Unclear still makes sense as "assign prio"?

Taylor Cramer (Sep 24 2019 at 17:49, on Zulip):

I thought I was responding to the book chat

nikomatsakis (Sep 24 2019 at 17:49, on Zulip):

lol :)

nikomatsakis (Sep 24 2019 at 17:49, on Zulip):

yes, parallel conversations...

Taylor Cramer (Sep 24 2019 at 17:49, on Zulip):

where you said > nikomatsakis: But I guess we don't need a meeting to do that

Taylor Cramer (Sep 24 2019 at 17:49, on Zulip):

sorry about that

Taylor Cramer (Sep 24 2019 at 17:49, on Zulip):

Yes, I agree we should keep this weekly meeting

nikomatsakis (Sep 24 2019 at 17:49, on Zulip):

I think we can roll the book updates into this meeting, perhaps

Taylor Cramer (Sep 24 2019 at 17:49, on Zulip):

mhm

nikomatsakis (Sep 24 2019 at 17:49, on Zulip):

I consider the book part of our output :)

centril (Sep 24 2019 at 17:50, on Zulip):

@nikomatsakis sure; if initial experimentation pans out most of the work might be to fix hir::ExprKind::Type to behave correctly

nikomatsakis (Sep 24 2019 at 17:51, on Zulip):

-Unclear still makes sense as "assign prio"?

maybe @centril somehing like

- AsyncAwait-Focus -- things we are doing now
- AsyncAwait-OnDeck -- things nominated as "maybe do next"
- AsyncAwait-Other -- other things :)

That said, I wonder if we should try a github project for this.

nikomatsakis (Sep 24 2019 at 17:51, on Zulip):

I've traditionally been kind of down on them though and I still sort of feel like it'd be more annoying than issue lists :)

centril (Sep 24 2019 at 17:51, on Zulip):

I like labels because they are not so mutually exclusive personally

centril (Sep 24 2019 at 17:52, on Zulip):

@nikomatsakis Yeah that labeling system works, it's basically high/med/low renamed :P

nikomatsakis (Sep 24 2019 at 17:52, on Zulip):

yes but in particular most things are "low"

nikomatsakis (Sep 24 2019 at 17:52, on Zulip):

except i'm not calling it that

nikomatsakis (Sep 24 2019 at 17:52, on Zulip):

my vision would be that focus is like 2-5 items, focus is < 1 page, and other is however big it has to be :)

centril (Sep 24 2019 at 17:53, on Zulip):

makes sense

nikomatsakis (Sep 24 2019 at 17:53, on Zulip):

I would also say do not add any label for new things

nikomatsakis (Sep 24 2019 at 17:53, on Zulip):

and thus unlabeled things are "triage"

nikomatsakis (Sep 24 2019 at 17:53, on Zulip):

(but will almost certainly go to other)

nikomatsakis (Sep 24 2019 at 17:54, on Zulip):

ok, cool, let's see how this works out... :)

centril (Sep 24 2019 at 17:54, on Zulip):

from a triage perspective it seems simplest to have an -Untriaged label sorta

centril (Sep 24 2019 at 17:54, on Zulip):

I think we can separate out things like async_closures that are not stable also

nikomatsakis (Sep 24 2019 at 17:54, on Zulip):

as you choose. seems like strictly more work to me

centril (Sep 24 2019 at 17:54, on Zulip):

focus on improving what is stable

centril (Sep 24 2019 at 17:54, on Zulip):

@nikomatsakis maybe you're right

nikomatsakis (Sep 24 2019 at 17:54, on Zulip):

the idea being "asyncawait labels" are things we add for our own purposes

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

( triage group adds "area" label )

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

my main concern is:

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

if you have a -Untriaged label

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

you have the potential for things to fall through the cracks

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

that never got any label at all

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

unless you also search for "no label"

nikomatsakis (Sep 24 2019 at 17:55, on Zulip):

at which point...

centril (Sep 24 2019 at 17:55, on Zulip):

So you need label:A-async-await -label:Async-Await-Focus -label:Async-Await-OnDeck -label:Async-Await-Other right?

centril (Sep 24 2019 at 17:56, on Zulip):

(those being the untriaged ones)

nikomatsakis (Sep 24 2019 at 17:56, on Zulip):

@centril right -- that's the link in this page

nikomatsakis (Sep 24 2019 at 17:56, on Zulip):

(except with different label names)

nikomatsakis (Sep 24 2019 at 17:56, on Zulip):

that is, the "uncategorized issues"

centril (Sep 24 2019 at 17:57, on Zulip):

@nikomatsakis excellent, so we remove -Unclear then

nikomatsakis (Sep 24 2019 at 17:57, on Zulip):

OK, are you going to edit the labels? Shall I?

nikomatsakis (Sep 24 2019 at 17:57, on Zulip):

I can do it right now...

centril (Sep 24 2019 at 17:57, on Zulip):

@nikomatsakis feel free to it; I'll make some :tea: :slight_smile:

nikomatsakis (Sep 24 2019 at 18:00, on Zulip):

done

nikomatsakis (Sep 24 2019 at 18:00, on Zulip):

I'll also update the compiler-team page

centril (Sep 24 2019 at 18:00, on Zulip):

Moved https://github.com/rust-lang/rust/issues/60424 to -Focus

nikomatsakis (Sep 24 2019 at 18:42, on Zulip):

Opened https://github.com/rust-lang/compiler-team/pull/183 which desribes the new organization

nikomatsakis (Sep 24 2019 at 18:42, on Zulip):

Spent..kind of way too long working on that

Last update: Nov 18 2019 at 00:35UTC