🐛 improve accuracy of MethodReference matches #97
Conversation
Signed-off-by: Pranav Gaikwad <pgaikwad@redhat.com>
...dle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/MethodCallSymbolProvider.java
Show resolved
Hide resolved
Signed-off-by: Pranav Gaikwad <pgaikwad@redhat.com>
| if (declaringClass != null) { | ||
| String fullyQualifiedName = declaringClass.getQualifiedName() + "." + binding.getName(); | ||
| // match fqn with query pattern | ||
| if (fullyQualifiedName.matches(getCleanedQuery(query))) { |
There was a problem hiding this comment.
what does getCleanedQuery do?
There was a problem hiding this comment.
@shawn-hurley updated that part of the code in my recent commit...search queries like get* are not valid regexes when it comes to Java regexes. So when matching the fqn, we need to make sure get* converts to get.* so it java regex works as expected.
added a comment
/*
* When comparing query pattern with an actual java element's fqn
* we need to make sure that * not preceded with a . are replaced
* by .* so that java regex works as expected on them
*/
...yzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java
Show resolved
Hide resolved
|
Looks good 👍 |
Signed-off-by: Pranav Gaikwad <pgaikwad@redhat.com>
| } | ||
| // sometimes binding or declaring class cannot be found, usually due to errors | ||
| // in source code. in that case, we will fallback and accept the match | ||
| this.symbolMatches = true; |
There was a problem hiding this comment.
This will lead to false positives, but I would rather that than miss real issues (which would happen if we did the opposite). I think this is the right approach.
There was a problem hiding this comment.
@shawn-hurley yes, this was what was causing errors in our test suite where some projects are outright bad / un-buildable etc. that was about 20% of total test cases that used METHOD_CALL. I think we can live with this tradeoff
This reverts commit 3b8cb13.
This PR improves accuracy of some searches: