Daniel Sun created GROOVY-12753:
-----------------------------------
Summary: STC fails to resolve receiver type arguments when
choosing among generic overloads
Key: GROOVY-12753
URL: https://issues.apache.org/jira/browse/GROOVY-12753
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Reporter: Daniel Sun
h3. Background
GROOVY-7204 and GROOVY-8059 both covered static type checking of overloaded
methods whose parameter types are type parameters of a generic receiver (for
example a Spring-style {{CrudRepository<T, S>}} with {{delete(T)}} and
{{delete(S)}}). Those issues were resolved and closed some time ago. Residual
cases remain where the type checker still ranks candidates against the unbound
type-parameter names instead of against the arguments of the concrete receiver
type, and where non-{{Class}} receivers lose their generic arguments when
methods are looked up.
This ticket describes that remaining problem space. Work in progress: [PR
#3261|https://github.com/apache/groovy/pull/3261].
h3. Problem
When {{StaticTypeCheckingSupport.chooseBestMethods}} has several candidates
that differ only in type-parameter positions, it measures argument-parameter
distance before substituting the receiver's type arguments into those
parameters. For a receiver such as {{MyRepository extends
CrudRepository<String, Long>}}, a call {{r.delete('foo')}} should prefer
{{delete(String)}} over {{delete(Long)}}. Without the substitution, both
parameters still look like free type variables and the call is rejected or the
wrong overload is chosen.
A related gap is that {{StaticTypeCheckingVisitor.visitMethodCallExpression}}
does not always keep generic type arguments on a non-{{Class}} receiver when it
calls {{findMethod}}, so even a correct distance measure never sees the
instantiation.
Nested classes add a further case: type arguments declared on an enclosing
class must stay visible when the receiver is a nested type that mentions those
enclosing parameters.
h3. Expected behaviour
* For a receiver whose type arguments bind the method's type-parameter
positions, overload ranking uses the substituted parameter types.
* When no candidate matches after substitution, ranking falls back to erased
parameter distance so single-target mismatch diagnostics stay unchanged.
* Non-{{Class}} receivers keep their generic arguments through method lookup.
* Type arguments from enclosing classes remain visible when binding a nested
receiver.
h3. Reproducer (sketch)
A type-checked {{MyRepository extends CrudRepository<String, Long>}} with
{{delete(T)}} / {{delete(S)}} overloads, and a call {{r.delete('foo')}} on a
{{MyRepository}} value. The call should compile and select {{delete(String)}}.
The same pattern for abstract classes and for nested types that close over
enclosing type arguments is covered by the suite attached to PR #3261
({{Groovy7204}} and related STC tests).
h3. Scope
Fix the residual STC ranking and receiver-binding behaviour described above. Do
not reopen GROOVY-7204 or GROOVY-8059; link them as related history.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
