Skip to content
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

Adds support for arrow functions from PHP 7.4 #65

Merged
merged 2 commits into from
May 3, 2021

Conversation

cfroystad
Copy link
Collaborator

@cfroystad cfroystad commented Apr 13, 2021

rfc

I'm not sure if the we should have different nodes for arrow_function and anonymous_arrow_function or the anonymous_arrow_function should alias to the array_function name?

What do you think?

Edit 2021.04.17:
Changed the implementation to always return the arrow_function node

@cfroystad
Copy link
Collaborator Author

Reworked the node structure to be more consistent with the rest of the grammar. I think this is ready for review when you find the time :)

Copy link
Contributor

@patrickt patrickt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, but I am a little confused as to why the parser size increased by 13k lines. Maybe @maxbrunsfeld can weigh in? Or is it the alias there?

@patrickt
Copy link
Contributor

By the way, I don’t think the parser increase is a show-stopper, given that PHP is one of the faster tree-sitter parsers around. Would just like to figure it out. :)

grammar.js Outdated
_anonymous_arrow_function: $ => seq(
$._arrow_function_header,
field('body', alias($._expression, $.expression_statement))
),
Copy link
Contributor

@maxbrunsfeld maxbrunsfeld Apr 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain what this _anonymous_arrow_function is for? It seems like the same thing as arrow_function, except that there's no trailing semicolon in the body, because the body is only an expression, not an expression_statement. It makes sense that this creates a fair amount of ambiguity e.g. in cases where an arrow function is followed by a semicolon.

Just for my understanding - why not just have the body of arrow_function be an expression (like _anonymous_arrow_function is now), and remove _anonymous_arrow_function entirely? In other words, why would an arrow function ever need to have a trailing semicolon inside of it (as opposed to after it)? Could you give an example of code that wouldn't parse correctly with that structure?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the RFC, I think arrow function bodies should always be expressions (not expression statements). I think we just need one arrow_function rule. Let me know if there's something I'm missing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good questions!

Adding both of them was the only way I could find to make the parser handle ; correctly in the different cases in the beginning. However I should have revisited that before thinking the PR done, cause you're perfectly correct - they should always just be expression.

Thank you for the guidance and sorry for not solving that before bugging you :)

Code updated

@cfroystad
Copy link
Collaborator Author

Parser size before: 1664 states, 85034 lines
Parser size after: 1754 states, 90072 lines

Copy link
Contributor

@maxbrunsfeld maxbrunsfeld left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making that update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants