-
Notifications
You must be signed in to change notification settings - Fork 665
feat: unknown bindings and unknown patterns #1804
feat: unknown bindings and unknown patterns #1804
Conversation
Test262 comparison coverage results on ubuntu-latest
|
Test262 comparison coverage results on windows-latest
Failed tests (16):
|
Were those new tests added manually into the |
What do you mean by "extracted"? Yes, I created manually the tests. Myself and Micha have been adding new tests in the |
The tests themselves would work as intended, but I think the idea is that you add the test cases "inline" to comments right next to the parser code they're testing and then the codegen extracts those comments into the So for example, these ok tests come from here and these err tests come from here. |
Damn! I wished there was some documentation somewhere! If there was, I couldn't find it anywhere! Thank you for letting me know, I will change that right away! |
@MichaReiser I restored your tests by adding the new cases as commented code. |
ce04d04
to
33fa14f
Compare
Thanks ema. How can I generate the inline tests? Is it a macro? |
It's an xtask: This will generate the JS files out of the comments. Then we run the command to update the .rast files. I guess we should start documenting all these findings |
24629d5
to
da8e59a
Compare
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.
This looks good to me, but I haven't personally worked much with the internals of this part of the parser.
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.
Looks good and thanks for recovering the tests.
The one thing I would change is to not distinguish between binding and pattern and only use JS_UNKNOWN_PATTERN
because the current grammar doesn't make the distinction as well (that's what I've been working on when extracting assignment targets, and then later introduce bindings).
We may need to give this a second pass once we have refined our approach to error recovery.
p.error(err); | ||
} | ||
|
||
if p.at(T![await]) && p.state.in_async { | ||
let err = p | ||
.err_builder("Illegal use of `await` as an identifier in an async context") | ||
.primary(p.cur_tok().range, ""); | ||
|
||
kind_to_change = JS_UNKNOWN_BINDING; |
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.
There were some more unknown bindings ;)
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.
Sorry @MichaReiser , I make this change later in another PR
Summary
This PR adds more test cases and adds the correct unknown nodes inside existing test cases:
eval
,argments
andyield
will emitJS_UNKNOWN_BINDING
let
will emit aJS_UNKNOWN_BINDING
JS_UNKNOWN_PATTERN
JS_UNKNOWN_PATTERN
JS_UNKNOWN_BINDING
Please refers to the new tests in the PR for more details. Make sure to search for
JS_UNKNOWN_BINDING
andJS_UNKNOWN_PATTERN
.Test Plan