Search for references: potential matches?

[mauromol]

Consider this:

package test53
import groovy.transform.CompileStatic
@CompileStatic
class MyBean {
	String foo	
}

and this:

package test53
import groovy.transform.CompileStatic
@CompileStatic
class Test53 {
	
	void doSomething() {
		def b = new MyBean()
		b.foo = 'foo'
	}
}

Go to MyBean.foo and hit Ctrl+Shift+G (search for references). Greclipse finds b.foo in b.foo = 'foo' in Test53, but marks it as a potential match: why potential?

[eric-milles]

why potential?

This search result is marked as a potential match because the search is for a field and the occurrence is actually a method call. If the match was exact, then a rename of the method from "getFoo" to "getWhatever" would change this reference to "getWhatever" instead of the expected "whatever". It is a bit of a balancing act to support find occurrences, call hierarchy, and rename refactoring for Groovy properties.

[mauromol]

This search result is marked as a potential match because the search is for a field and the occurrence is actually a method call. If the match was exact, then a rename of the method from "getFoo" to "getWhatever" would change this reference to "getWhatever" instead of the expected "whatever". It is a bit of a balancing act to support find occurrences, call hierarchy, and rename refactoring for Groovy properties.

I understand the fact that this match is actually a method call, but I can't follow you on the rename example. getFoo() is not explicitly defined, so I can't rename it to getWhatever(): what I can do, instead, is to rename foo to whatever and in this case I would expect that reference to be changed to whatever indeed.

I think it's a bit confusing the fact that references are marked as "potential". Maybe this is a limitation that needs to be in place to make other things (like refactorings) work in the right way... but, from a user point of view and without any knowledge of the internals, in this example I would expect Eclipse to treat the match as exact, especially because I'm using static compilation, so I would say it's certain that I'm referring to that property and not potentially to something else.

[eric-milles]

Here is one difference:

void meth(Bean b) {
  b.foo // ConstantExpression[foo]
    = 'foo'
}

@groovy.transform.CompileStatic
void meth(Bean b) {
  b.foo // ConstantExpression[setFoo]
    = 'foo'
}

This is causing the switch from exact to potential.

[mauromol]

And again, from an ignorant like me point of view, I would say the first case is more likely to be "potential" due to the dynamic nature of Groovy, while the second one is more likely to be "exact" due to the fact that the call is statically compiled in. That is, the opposite of what happens right now :-)

[eric-milles]

This will get sorted out. I just discovered this difference upon investigating your issue. I think in the end, both the dynamic and static case can be shown as exact matches.

[eric-milles]

ready to test

[mauromol]

This use case works well with 3.5.0.v201908101728-e1906: no "exact"/"potential" match indication is shown, hence the match must be exact, which is what I expect. Thank you!