-
-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: update parser #1270
feat: update parser #1270
Conversation
c95c3bd
to
dee0ea6
Compare
dee0ea6
to
883adb1
Compare
This adds support for the spread operator for arrays (PHP 7.4) and fixes an issue with silent / retif precedence. Fixes #1009
883adb1
to
0fc2113
Compare
@loilo ready for review. Not sure why appveyor is still running... |
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 may want to check the GitHub Actions CI pipeline.
It doesn't catch an error I encounter locally (in yarn test tests/parens
): A cast
node doesn't seem to have an expr
property, the error looks genuine:
FAIL test-node tests/parens/jsfmt.spec.js
● Test suite failed to run
TypeError: Cannot read property 'comments' of undefined
2555 | node.type,
2556 | ") ",
> 2557 | node.expr.comments
| ^
2558 | ? indent(path.call(print, "expr"))
2559 | : path.call(print, "expr")
2560 | ]);
at comments (src/printer.js:2557:19)
You’re probably still using an old (cached) version of the parser. Try running In the latest version of the parser “what” has been renamed to “expr” on cast nodes. |
Right, that fixed it. And I thought that's one of the things a lockfile should prevent. 🙄 |
Seems like that's an open issue in yarn: yarnpkg/yarn#4722 Good to go? 😉 |
Gimme a second, just doing the actual review now. Was too tired yesterday. 😁 Everything looks about right to me, but I have some questions to better understand the changes, gonna put them in review comments. |
case "entry": { | ||
const ref = node.byRef ? "&" : ""; | ||
const unpack = node.unpack ? "..." : ""; | ||
return node.key |
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 I understand this correctly that this differentiation is needed because of PHP 7.4 array unpacking and no key
is available when unpacking something?
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.
With the new parser version, entry
objects are created for every array entry, not just for associative arrays anymore (see old behavior here). Also, unpack
and byRef
were added to the entry
node for a generic way to describe the context of a specific entry.
So with the new version, we have to account for entry
s that don't have a key
(non-associative arrays).
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.
Alright, this explains my follow-up question as well (why we didn't previously differentiate beetween kinds of array entries). 😁
What I discovered (but I need to create an issue over at the parser for that): It's possible to do [...&$var]
which should cause a parser error instead.
case "entry": { | ||
const ref = node.byRef ? "&" : ""; | ||
const unpack = node.unpack ? "..." : ""; | ||
return node.key |
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.
Alright, this explains my follow-up question as well (why we didn't previously differentiate beetween kinds of array entries). 😁
What I discovered (but I need to create an issue over at the parser for that): It's possible to do [...&$var]
which should cause a parser error instead.
See also: glayzzle/php-parser#461 |
Good job! |
This adds support for the spread operator for arrays (PHP 7.4) and fixes
an issue with silent / retif precedence.
Fixes #1009