Hey @WG-async-foundations, sync meeting?
I'm just back from vacation last week
ICE on rustc 1.41.0-nightly (25d8a9494 2019-11-29) running on x86_64-apple-darwin #66958
narrowed down to https://github.com/rust-lang/rust/pull/66567
@Esteban Küber is on it, marking it as "triaged"
Slightly incorrect help message with mismatched typs in async code #66910
@Esteban Küber -- if you're around -- do you know if we do any suggestions that advise you to add
.await? is there an issue on that?
I'm going to go ahead and tag this as "on deck", seems like a good change to make
async_await RFC is not fully implemented, but tracking issue is closed #66909
specifically, it seems like there is missing docs for the keywords
It is quite a corner case but I think it makes sense to address. No need for me to fast track it, is there?
There is a ticket for suggesting await that is partly covered
@Esteban Küber I'm interested more in the general case of suggesting await
then in this specific case
The more complex cases like these will be trickier to handle, my worry is for foo.bar.future.baz
That was the reason to keep the original ticket open
I'm on mobile now, but I can fish it out later
I imagined we could check for any case where you have a type error between
impl Future<Output = T> and
And link the tickets
One thing to decide, right now we o ly suggest on 2018 and don't mention async await in 2015
not sure, good question
I'd be inclined to say "probably yes"
but I could go either way
iirc we do suggest it in 2015 somewhere; iirc I added that
that looks perfect, yeah
More friendly error msg when await on NONE ASYNC fn/block or return a obj that implements deprecated Future #66731
very confusing issue title
but basically the reverse problem
seems like a good suggestion, I will also "on deck" this one
hah; interesting -- so basically the suggestion is "add
asyncfunction/block produces errors for valid unrelated expressions #66634
this does seem annoying, but I'm not going to bump the priority I don't think
hah; interesting -- so basically the suggestion is "add async before fn"
seems like it could be a fairly targeted fix in typeck
yeah, that's what I was thinking too
I should leave a comment to that effect
I'm not sure if "on-unimplemented" is necessarily the right vector here
could be worth a try to see if that mechanism is cheaper before trying something custom
on-unimplemented would certainly be an easy way, not clear how important this case is
you won't get the nice suggestion
rustc crash on 1.39.0 stable with combination of
"crash" here means ICE
looks like there is a fix already
and it was beta-nominated etc
I'll mark as triaged, move on
RFC: process-handle for future async child-processes-term-handling #2817
It's needstest only
er, I guess that's a side-effect of using the "org-wide search" :)
If only async/await was stable in 2012 :D
I'm not really sure why that is tagged A-async-await
Symbols in optimized async programs are often not useful #65978
I guess I'll mark this as "triaged"
seems like a "nic to have"
@Steven Fackler landed a PR relevant to this one (which I reviewed)
ok, that's all the untriaged issue, and..that's the whole 30 minutes
I'll observe that we've lost some momentum, but, hey, it's the holidays. Seems ok. :)
(We do need to figure out how we're going to organize this group in a bigger sense, I think, I'm still wondering where the "leadership energy" will come from. Anyway who thinks they'd like to play more of a leadership and organizational role should ping me...)