API, Rustc: Add AwaitExpr and support async blocks and fns
#197
Conversation
xFrednet
added
C-enhancement
xFrednet
force-pushed
the
174-async-artificial-sweetening
branch
2 times, most recently
from
30dc508 to
919081a
Compare
| if let hir::ExprKind::Block(block, None) = block_expr.kind { | ||
| let api_block_expr; | ||
| let capture_kind = self.to_capture_kind(closure.capture_clause); | ||
| super::with_body!(self, body_id, { | ||
| api_block_expr = self.to_block_expr( | ||
| CommonExprData::new(self.to_expr_id(block_expr.hir_id), self.to_span_id(block_expr.span)), | ||
| block, | ||
| None, | ||
| Syncness::Async, | ||
| capture_kind, | ||
| ); | ||
| }); | ||
| return ExprKind::Block(self.alloc(api_block_expr)); | ||
| } | ||
| unreachable!("`async` block desugar always has the same structure") |
There was a problem hiding this comment.
I love early exits because they remove the nesting of code. This could instead be writen like so:
let hir::ExprKind::Block(block, None) = block_expr.kind else {
unreachable!("`async` block desugar always has the same structure");
};
// The rest of the code here one level closer to the left side of the screenI know rust linting is a pretty deterministic process. If this code was part of a distributed system where flaky random glitches are possible I'd recommend putting as much info in the panic/error message as possible, because reproducing a problem may not be realistically possible
There was a problem hiding this comment.
I often find let else statements less readable. It would be cool if if-let chains would be stabilized, but they sadly disable rustftm for the function
Thank you very much! That you provided feedback on the code was already way more than I expected. I really appreciate it ❤️ |
xFrednet
force-pushed
the
174-async-artificial-sweetening
branch
from
919081a to
0bd55d7
Compare
|
I rebased and addressed the review comments this should be ready now. |
|
I believe it's safe to r+ this :) bors r+ |
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
Basically, what the title says :D
Async and await stuff in rustc heavily relies on syntax sugar. A simple
.awaitcall is transformed into one loop and two match statements etc. This far Marker has always resugared this syntax, for two reasons:In this case, I've decided to also resugar the expressions. For
.awaitexpressions, I'm sure that this is the right call. However, async blocks and functions might be different. For example:The function actually has the return type
impl Future<Output = u8>and notu8like the AST node currently says. Theimpl Future<Output = u8>can still be retrieved as the semantic type of the expression.The basic question I currently have is: Is resugaring the output of the function to
u8okay, or should it still sayimpl Future<Output = u8>even if the user didn't write it? Personally, I like this resugar, but I haven't worked too much with async.@Veetaha you said previously that you work with async. Do you maybe have any thoughts on this? (I hope it's okay that I ping you, if not, please tell me, and I will refrain from it in the future)
Closes #174