fix: Strip parameter types from METHOD_CALL patterns

[tsanders-rh]

Description

Fixes konveyor/analyzer-lsp#854

This PR fixes a bug where METHOD_CALL rules with patterns containing parameter types (e.g., java.util.Properties.setProperty(java.lang.String, java.lang.String)) fail to match actual method calls.

Problem

When users specify METHOD_CALL patterns with parameter types, the CustomASTVisitor was failing to match these patterns because:

1. The AST resolves method names as ClassName.methodName without parameter types
2. The query pattern still contained parameter types like (Type1, Type2)
3. The regex match would fail due to this mismatch

Solution

Added preprocessing in the CustomASTVisitor constructor to strip parameter types (everything within parentheses) from the query pattern before applying other transformations. This allows patterns with parameter types to match correctly against the AST-resolved method names.

Example

• Input pattern: java.util.Properties.setProperty(java.lang.String, java.lang.String)
• Processed pattern: java.util.Properties.setProperty
• AST method name: java.util.Properties.setProperty
• Result: ✅ Match successful

Test Case

The issue can be reproduced with the following rule against the examples/customers-tomcat-legacy project in analyzer-lsp:

- message: "Found usage of java.util.Properties.setProperty method"
  ruleID: test-setproperty-00001
  when:
    java.referenced:
      location: METHOD_CALL
      pattern: java.util.Properties.setProperty(java.lang.String, java.lang.String)

This rule should trigger on lines 68-70 in src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java but previously did not.

Changes

• Modified CustomASTVisitor.java constructor to strip parameter types using regex \([^)]*\) before other query transformations

Summary by CodeRabbit

• Bug Fixes
  • Improved symbol query matching for methods, constructors, and annotations. Queries that include parameter type information are now processed with enhanced accuracy. This results in more precise pattern matching while preserving backward compatibility with existing queries.

[coderabbitai]

Walkthrough

Modified the CustomASTVisitor constructor to preprocess query strings by stripping method parameter types before applying star-wildcard regex pattern matching, altering how ANNOTATION/METHOD_CALL/CONSTRUCTOR_CALL paths match patterns that include parameter type specifications.

Changes

Cohort / File(s)	Summary
Query parameter preprocessing java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java	Added preprocessing step in constructor to strip method parameter types from incoming query strings prior to regex application, preserving fallback behavior for existing queries

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Attention area: Logic for parameter type stripping and how it interacts with existing regex pattern matching for different query paths (ANNOTATION/METHOD_CALL/CONSTRUCTOR_CALL)
• Verification needed: Confirm the preprocessing correctly handles edge cases and doesn't unintentionally strip legitimate parts of query patterns

Poem

🐰 A property setter was lost in the woods,
No parameters passed, misunderstood!
But a rabbit came by with regex in hand,
Stripped types from queries across the land—
Now setProperty calls are finally found,
Happy hopping on matching ground! 🎉

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: stripping parameter types from METHOD_CALL patterns to fix pattern matching.
Linked Issues check	✅ Passed	The PR directly addresses issue #854 by implementing the solution to strip parameter types from METHOD_CALL patterns, enabling rules with parameter types to match AST-resolved method identifiers.
Out of Scope Changes check	✅ Passed	All changes are scoped to fixing the METHOD_CALL pattern matching issue; no unrelated modifications or scope creep detected in the CustomASTVisitor constructor preprocessing logic.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7e0cb5d and de74997.

📒 Files selected for processing (1)

• java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Build tackle2-addon-analyzer

🔇 Additional comments (1)

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (1)

44-57: Test coverage verification required — no test cases found for this fix.

The parameter stripping logic is sound. The regex \\([^)]*\\) correctly processes patterns like setProperty(java.lang.String, java.lang.String) → setProperty, and the two-step approach (strip params first, then convert wildcards) is correct.

However, a comprehensive search of the test module found:

• No unit tests for CustomASTVisitor or its three consuming providers (MethodCallSymbolProvider, ConstructorCallSymbolProvider, AnnotationSymbolProvider)
• Only one integration test file exists (SampleDelegateCommandHandlerTest.java), which does not exercise the symbol providers with method patterns
• No test resources, fixtures, or test data with patterns containing parameter types

Before merging, please verify:

• Test cases exist elsewhere in the codebase (e.g., separate test module) and confirm they cover patterns with parameter types
• If not, add unit tests exercising the fix with cases like ClassName.method(Type1, Type2) and verify they correctly match AST elements

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[jmle]

We need to be able to match parameter types too

[tsanders-rh]

@jmle - Agreed. Opened this yesterday: #182