-
Notifications
You must be signed in to change notification settings - Fork 656
Function Expression/Declaration AST Facade #1786
Conversation
let m = p.start(); | ||
p.bump_remap(T![async]); | ||
let mut complete = function_decl( | ||
&mut *p.with_state(ParserState { | ||
in_async: true, | ||
..p.state.clone() | ||
}), | ||
m, | ||
true, | ||
); | ||
complete.change_kind(p, FN_EXPR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We repetitively parsed the async
keyword. I decided to move the consumption of the async
keyword into function_expression
/function_declaration
. This fixes multiple issues where the async
identifier wasn't correctly re-mapped to the async
keyword.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there new tests for this new logic? I get we fixed some bugs, but are they reflected inside some test?
// TODO 1725 This is probably not ideal (same with the `declare` keyword). We should | ||
// use a different AST type for function declarations. For example, a function declaration should | ||
// never have a body but that would be allowed with this approach. Same for interfaces, interface | ||
// methods should never have a body | ||
/// Either parses a typescript declaration body or the function body |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only copied this method which is why I didn't address the declare
problem.
Deploying with
|
Latest commit: |
834e34a
|
Status: | ✅ Deploy successful! |
Preview URL: | https://fd7cfb27.tools-8rn.pages.dev |
p.eat(T![declare]); | ||
} | ||
|
||
let in_async = p.at(T![ident]) && p.cur_src() == "async"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think makes sense to have eat_if and bump_remap_if methods?
let in_async = p.bump_remap_if(T![async], p.at(T![ident]) && p.cur_src() == "async");
// let in_async = p.eat_if(T![ident], p.cur_src() == "async");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally like the explicit control flow of the if
, I find this clearer than too inline condition. However, something like that may come in handy when I work on signalling the "missing" slots but I don't know exactly how the API would look like.
That's why I prefer to defer to delay adding any such methods until I have a better understanding of the requirements.
1476ad6
to
77c6cc8
Compare
c64a86e
to
c650a2b
Compare
* Rename `FnDecl` to `JsFunctionDeclaration` * Rename `ParameterList` to `JsParameterList` * Introduce `TsReturnType` to group the `: Type` * Restructure parsing implementation of function decl/expression * Introduce `JsRestParameter`
c650a2b
to
3281bb3
Compare
let m = p.start(); | ||
p.bump_remap(T![async]); | ||
let mut complete = function_decl( | ||
&mut *p.with_state(ParserState { | ||
in_async: true, | ||
..p.state.clone() | ||
}), | ||
m, | ||
true, | ||
); | ||
complete.change_kind(p, FN_EXPR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there new tests for this new logic? I get we fixed some bugs, but are they reflected inside some test?
block_impl(p, JS_FUNCTION_BODY, None) | ||
} | ||
|
||
// TODO 1725 This is probably not ideal (same with the `declare` keyword). We should |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you add a hash #
before the issue number (#1725
), it integrates with VSCode/Idea and it will show the issue inside the editor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh neat!
Yes, I added new tests |
Summary
Updates the facade for function declarations and function expression to match the grammar defined in #1719.
FnDecl
toJsFunctionDeclaration
ParameterList
toJsParameterList
JsIdentifierBinding
type forid
...rest
asJS_REST_PARAMETER
instead ofJS_REST_PATTERN
.TsReturnType
for the:
and the return typeFnExpr
toJsFunctionExpression
ArrowExpr
toJsArrowFunctionExpression
ExprOrBlock
toJsAnyArrowFunctionBody
This PR cleans up some of the function parsing (extracts helpers rather than using boolean params). This improves error reporting for the
func_decl
use case if the name is missing.This PR also removes the support for decorators. The parser had some support for decorators but they haven't been part of the grammar. We should re-add them when we decide to properly support them (and add tests)
Part of #1725
Test Plan
Verified that the coverage isn't changing.