You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
packagetest22importgroovy.transform.CompileStatic@CompileStaticclassTest22 {
publicTest22() {
def b =newMyBean(foo: 'c')
def m = b.&setFoo
}
}
Invoke Call Hierarchy on MyBean.setFoo(String): I think the reference to this method in def m = b.&setFoo should not be lost and shown in the Call Hierarchy in some way.
Creating an equivalent Java Class and using a method reference (which is much like a Groovy method pointer), I see it shown in Call Hierarchy just like a regular call. We could argue that is not really a "call" (at least where it's just assigned), but at least it is not lost. So perhaps Greclipse should at least mimic what JDT does.
Here's an "equivalent" Java class to test the behaviour:
org.eclipse.jdt.groovy.search.MethodReferenceSearchRequestor.acceptASTNode(ASTNode, TypeLookupResult, IJavaElement) finds the desired reference, but returns it as an "inaccurate" match and so the Call Hierarchy does not show it.
Something like a follow-up to #489:
Consider this Java class:
And this Groovy class:
Invoke Call Hierarchy on
MyBean.setFoo(String)
: I think the reference to this method indef m = b.&setFoo
should not be lost and shown in the Call Hierarchy in some way.Creating an equivalent Java Class and using a method reference (which is much like a Groovy method pointer), I see it shown in Call Hierarchy just like a regular call. We could argue that is not really a "call" (at least where it's just assigned), but at least it is not lost. So perhaps Greclipse should at least mimic what JDT does.
Here's an "equivalent" Java class to test the behaviour:
The text was updated successfully, but these errors were encountered: