-
Notifications
You must be signed in to change notification settings - Fork 70
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
fix: invalid parsing of traitalias #402
base: prettier
Are you sure you want to change the base?
Conversation
|
||
const visibility = this.read_member_modifier(); | ||
|
||
switch (visibility) { |
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.
Need refactor too, let's do it in next PRs
"message": "Parse Error : syntax error, unexpected 'abstract' (T_ABSTRACT) on line 3", | ||
"token": "'abstract' (T_ABSTRACT)", | ||
"message": "Parse Error : syntax error, unexpected 'function' (T_FUNCTION) on line 3", | ||
"token": "'function' (T_FUNCTION)", |
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.
Expected because it is not grammatical problem, i think we should remove this check in future, we are parser not virtual machine for execution, so all runtime errors should be parsable
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.
Hi @evilebottnawi,
I'm not agree with you - with this change you validate every invalid PHP token that is checked on runtime level over the AST.
Take this example : interface foo { abstract function bar(); }
- in PHP it will allways trigger an fatal error.
I thing we should consider the 2 approaches :
1- first would be to parse the grammar as you indicate and forget runtime checks. That would imply you can not rely on the library to check the PHP syntax, and we would need an external tool for linting the resulting AST (including PHP runtime checks)
2- or handle that kind of problem directly into the parser as it was done since, and use a gracefull mode to ignore any syntax error
As nobody wants to handle broken PHP syntax, and if you need to parse it anyway you have a graceful
flag for this, I prefer to keep extra runtime checks on the parser level.
The reason for me it's about syntax rules - it has no meaning to have an interface with an abstract function, PHP does not permit it anyway.
I think they gave an incomplete or simplified version of the grammar (due to simplifications or technical issues) so PHP needs extra check on runtime to filter syntax errors.
By not filtering every syntax errors (based on php documentation and not only on grammar file) you have a sort of graceful mode on various grammar problems, only justified by implementation choices of Zend team...
Lets do it like before, it's not about VM, it's about valid syntax or not, if it's not, you need to trigger an error
c2e2bc4
to
7c09272
Compare
"message": "Parse Error : syntax error, unexpected 'abstract' (T_ABSTRACT) on line 3", | ||
"token": "'abstract' (T_ABSTRACT)", | ||
"message": "Parse Error : syntax error, unexpected 'function' (T_FUNCTION) on line 3", | ||
"token": "'function' (T_FUNCTION)", |
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.
Hi @evilebottnawi,
I'm not agree with you - with this change you validate every invalid PHP token that is checked on runtime level over the AST.
Take this example : interface foo { abstract function bar(); }
- in PHP it will allways trigger an fatal error.
I thing we should consider the 2 approaches :
1- first would be to parse the grammar as you indicate and forget runtime checks. That would imply you can not rely on the library to check the PHP syntax, and we would need an external tool for linting the resulting AST (including PHP runtime checks)
2- or handle that kind of problem directly into the parser as it was done since, and use a gracefull mode to ignore any syntax error
As nobody wants to handle broken PHP syntax, and if you need to parse it anyway you have a graceful
flag for this, I prefer to keep extra runtime checks on the parser level.
The reason for me it's about syntax rules - it has no meaning to have an interface with an abstract function, PHP does not permit it anyway.
I think they gave an incomplete or simplified version of the grammar (due to simplifications or technical issues) so PHP needs extra check on runtime to filter syntax errors.
By not filtering every syntax errors (based on php documentation and not only on grammar file) you have a sort of graceful mode on various grammar problems, only justified by implementation choices of Zend team...
Lets do it like before, it's not about VM, it's about valid syntax or not, if it's not, you need to trigger an error
Hi @evilebottnawi, not sure what to do with this PR, can we review it on 3.1 or does it introduce breaking changes ? |
Yes, let's do it in |
read_*
for better maintenanceIt is invalid and should not be parsable.