You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I thought I needed this once or twice, but have gotten around it by pre-processing the async class, post-processing a generated AST, or parsing once, processing, and parsing again. The most interesting cases are those where the text the grammar would accept is modified by the results of an async call that uses information parsed from the input.
There will have to be an option that affects code generation.
Discussion:
I assume this is going to have a pretty big negative impact on performance, but let's measure it.
Does every parse function get marked as async? I don't see any good way around it, since an otherwise-sync rule might call an async one.
Determining if a rule should be run in an async context would be difficult without a full parse of the code in result and predicate blocks, or a mechanism for the async flag to a rule's metadata
Tree shaking rules that were determined to be async might help, but that's likely to run into edge cases, and the top-level rule will always be async, which means the gains are likely to be minimal.
get this error :
await
could be allowed inside expression body function.The text was updated successfully, but these errors were encountered: