UnnecessaryExplicitTypeArguments: retain load-bearing witness in argument position on instance methods too

[neil-mushell]

What's changed?

Generalizes UnnecessaryExplicitTypeArguments's argument-position guard to retain a type witness on instance methods too, not just static ones, when the witness's type variables aren't inferable from the call's own arguments. Removes the now-redundant shouldRetainOnStaticMethod helper in favor of applying canInferTypeArgumentsFromArguments uniformly — the same check already used for the sibling select-position branch.

What's your motivation?

The argument-position branch only guarded static methods (via shouldRetainOnStaticMethod) against removing a witness whose type variables aren't inferable from the call's own arguments. Instance methods used as arguments skipped that guard entirely, so a witness like t.<STATE_VALUE>source() passed to a generic static factory Transition.of(...) got stripped even though STATE_VALUE has no argument to infer it from and the factory itself provides no target type, leaving STATE_VALUE unresolved.

We hit this piloting the recipe against a state-machine interpreter with recursive/self-bounded generics (StateMachineInterpreter<STATE_VALUE extends Enum<STATE_VALUE>, ...>), where it silently broke compilation.

Anything in particular you'd like reviewers to focus on?

Whether folding the argument-position and select-position branches into one shared check is worth a larger refactor — they both now reduce to "retain unless inferable from the call's own arguments" and only diverge afterward on the overload-ambiguity check, which is argument-position-only.

Anyone you would like to review specifically?

No specific request — open to whoever's around.

Have you considered any alternatives or workarounds?

Considered keeping shouldRetainOnStaticMethod's name/shape and just widening its condition (adding || !isStatic or similar). Removed it instead since "static-only" naming became misleading once the check applies to both static and instance methods, and both branches already share canInferTypeArgumentsFromArguments.

Any additional context

Full module suite: 2147 tests, 0 regressions from this change (one pre-existing intermittent failure in AllBranchesIdenticalTest.collapseIdenticalBranchesPython, reproduced independent of this diff — a flaky Python-parser round-trip test unrelated to this recipe). Added both a negative-case test (witness retained, matching the bug) and a positive-case test (witness still removed when inference from the call's own arguments is possible) to make sure the fix doesn't over-correct into blanket retention.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Thanks for coming back here with another round of fixes. Good to have this hardened against a code base with heavy usage.