-
Notifications
You must be signed in to change notification settings - Fork 805
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
[Analyzer] Fix fatal when trying to call toCodeString() in Node\Expr\Variable class #40855
Conversation
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Follow this PR Review Process:
Still unsure? Reach out in #jetpack-developers for guidance! |
@@ -152,6 +152,11 @@ public static function has_function_call( $node, $name ) { | |||
if ( ! $stmt instanceof Node\Stmt\Expression || ! $stmt->expr instanceof Node\Expr\FuncCall ) { | |||
continue; | |||
} | |||
|
|||
if ( $stmt->expr->name instanceof Node\Expr\Variable ) { |
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.
Should we have a positive check for Node\Expr\Variable
? The Node\Expr
has many more classes than just Variable
, if they appear in this flow ( I don't know if it is possible ) we can still encounter issues?
Would it be better to just check for the toCodeString
capability?
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.
Hey @budzanowski thanks for your comment. I agree it would be nicer to have a future-proof solution in case $stmt->expr->name
can be something else.
I was thinking about using method_exists for that, but that would make it fail if for instance $stmt->expr->name
is an array.
That's why I decided towards the simpler solution that Mik presented here peeuvX-1JR-p2#comment-2191 and just focus on fixing the problem we currently have. That way I'm sure I'm not breaking any other code somewhere using the JP Analyzer that I'm unfamiliar with. Another reason I lean over this simple solution is that I expected it to be reviewed and merged faster so both Ventures and Automata could perform the Compat Checking as always without the bug.
Happy to discuss a better solution if you have it in mind. So we can implement it in a future PR.
Proposed changes:
In order to mitigate this we need to fo thisnstep each time we perform a Compat Check, on every WC Release:
The fix tho is very simple so I hope it gets merged in the repo itself.
Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions: