[
https://issues.apache.org/jira/browse/GROOVY-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141461#comment-18141461
]
ASF GitHub Bot commented on GROOVY-12753:
-----------------------------------------
daniellansun commented on PR #3261:
URL: https://github.com/apache/groovy/pull/3261#issuecomment-6746561181
Thanks — opened GROOVY-12753 for the residual problem space (GROOVY-7204 /
GROOVY-8059 stay closed and are linked as related). Retitled this PR
accordingly and rebased onto current master (`fb665454`).
> 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
> Priority: Major
>
> 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)
