-
Notifications
You must be signed in to change notification settings - Fork 1.2k
fix: issue 4358 prevent infinite cycles with static imports #4359
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
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4359 +/- ##
=============================================
+ Coverage 51.853% 51.860% +0.007%
=============================================
Files 497 497
Lines 28326 28326
Branches 4916 4916
=============================================
+ Hits 14688 14690 +2
+ Misses 11597 11595 -2
Partials 2041 2041
Flags with carried forward coverage won't be shown. Click here to find out more. see 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
.setSymbolResolver(new JavaSymbolSolver(cts)); | ||
StaticJavaParser.setConfiguration(pc); | ||
CompilationUnit cu = StaticJavaParser.parse(issueResourcesPath.resolve("foo/A.java")); | ||
cu.findAll(MethodCallExpr.class).forEach(MethodCallExpr::resolve); |
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.
Can't we check the result because there's only one method call?
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.
I'll accept this solution because it doesn't break the existing tests.
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.
@jlerbsc The result is irrelevant, the test verifies that StackOverflowError
isn't thrown during resolve
. I considered adding a comment explaining it or explicitly using assertDoesNotThrow to make it more clear.
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.
Does this mean that the method is not correctly solved?
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.
It is correctly solved 😉. I could add the assertions to make it clear that:
- The method is correctly solved.
StackOverflowError
isn't thrown.
Should I do that?
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.
Checking that the method is correctly resolved is sufficient. If we want to find the context, we can refer to the issue.
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.
Sounds good to me.
Thanks for reviewing the change. I'll let you know when I implement the assertion, can't do it right now.
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.
As soon as it's done, I'll validate the PR. Thank you for your contribution.
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.
@jlerbsc Done. I also rebased my change onto current master.
Fixes #4358 (infinite loop when
import static
is used between an ancestor and parent class).