Stream: t-compiler/wg-rls-2.0

Topic: async move resolutions


Paul Faria (Aug 06 2020 at 13:59, on Zulip):

I just filed https://github.com/rust-analyzer/rust-analyzer/issues/5676 and I'm curious where I could start attempting to fix that issue. Is this internal to RA or does it come from one of the libraries like chalk?

Laurențiu Nicola (Aug 06 2020 at 14:02, on Zulip):

There are some mentoring instructions in https://github.com/rust-analyzer/rust-analyzer/issues/4018#issue-602093106. But in the meanwhile it seems we've got an Expr::Unsafe, so maybe it should be Expr::Async for symmetry

Florian Diebold (Aug 06 2020 at 14:02, on Zulip):

it's a bit of an open design question how to best model async blocks in the type system in rust-analyzer right now (as you can read in the issue I linked); we could use opaque types, but it would be a bit of a misuse; more proper would be generators, but they don't exist yet in Chalk's type library

Laurențiu Nicola (Aug 06 2020 at 14:02, on Zulip):

Is unsafe async {} a thing?

Paul Faria (Aug 06 2020 at 14:07, on Zulip):

Oh ok, should I close the one I filed as a duplicate then?

Florian Diebold (Aug 06 2020 at 14:07, on Zulip):

I already did

Paul Faria (Aug 06 2020 at 14:08, on Zulip):

Thanks!

Paul Faria (Aug 06 2020 at 14:09, on Zulip):

I might try to start tackling this after work today, or is there someone already working on it?

Paul Faria (Aug 06 2020 at 14:10, on Zulip):

Could this be implemented with opaque types to improve resolution, and we file an issue to move to generators once it's supported by chalk?

Florian Diebold (Aug 06 2020 at 14:14, on Zulip):

it could, but I'd rather improve Chalk than work around it

Paul Faria (Aug 06 2020 at 14:24, on Zulip):

I might be getting in over my head here, but where is the discussion room for chalk? I'll see if there any way I can help

Florian Diebold (Aug 06 2020 at 14:26, on Zulip):

#wg-traits . I think the chalk issue is rust-lang/chalk#504

Florian Diebold (Aug 06 2020 at 14:26, on Zulip):

it's probably actually not a complicated thing to add, since we don't need any built-in behavior for it, just the type itself, I think

Paul Faria (Aug 06 2020 at 14:39, on Zulip):

Ok, I'll ask there after work. Thanks!

Paul Faria (Aug 07 2020 at 00:29, on Zulip):

Looks like there's still someone working on it. I'll move on to something else for now.

Laurențiu Nicola (Aug 07 2020 at 05:54, on Zulip):

I think you can still work on the parser and IR support for async blocks

detrumi (Aug 07 2020 at 07:15, on Zulip):

Paul Faria said:

Looks like there's still someone working on it. I'll move on to something else for now.

If you mean chalk#504, that was assigned 2 months ago and I don't think there has been progress lately, so you could drop a comment asking if it's still being worked on

Paul Faria (Aug 07 2020 at 12:39, on Zulip):

@detrumi I had reached out to the person it was assigned to, and he said he still has some work left and was planning to put up a draft PR with his work so far.

Paul Faria (Aug 07 2020 at 12:41, on Zulip):

@Laurențiu Nicola I thought async was already tracked in the parser, similarly to how unsafe blocks are handled. What do you mean regarding IR support?

Laurențiu Nicola (Aug 07 2020 at 12:42, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ra_hir_def/src/expr.rs#L52-L55

Laurențiu Nicola (Aug 07 2020 at 12:42, on Zulip):

I was saying there's an Expr::Unsafe variant for unsafe blocks, but no variant for async ones and I wasn't sure if it should be a variant or an attribute of the block

Laurențiu Nicola (Aug 07 2020 at 12:43, on Zulip):

Hence my unsafe async {} question

Laurențiu Nicola (Aug 07 2020 at 12:50, on Zulip):

But yes, the parser accepts it IIRC

Last update: Sep 27 2020 at 13:15UTC