Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method not recognized when invoked from an anonymous inner class #378

Closed
mauromol opened this issue Nov 8, 2017 · 6 comments
Closed

Method not recognized when invoked from an anonymous inner class #378

mauromol opened this issue Nov 8, 2017 · 6 comments
Labels

Comments

@mauromol
Copy link

mauromol commented Nov 8, 2017

Consider the following Groovy class:

package test8
class A {
	protected def m() { }
	
	Object p = new Object() {
		String toString() {
			m()
		}
	}
	
	void init() {
		def whatever = new Object() {
		  def something() {
			m()
		  }
		}
	  }
  }

What I see is that m() call from the definition of A.p field (with an inner class) is underlined.
Instead m() call from the definition of whatever local variable is not underlined, by nevertheless it seems like the call is not recognized (F2 and F3 do not work).
Funny enough, if you comment out the p field definition, then the second call to m() becomes underlined :-)

@eric-milles
Copy link
Member

ready to test

@mauromol
Copy link
Author

With 2.9.2.xx-201711100505-e46 this works partially. If you use the use case I provided, now, the m() call from the anonymous inner class of p = assignment is recognized, while the m() call from the anonymous inner class of whatever = assignment is not. If you comment out the p assignment, then the second call is recognized, too.

You can see this by trying to refactor m to doSomething: you'll see that only the first method call is renamed.

@eric-milles
Copy link
Member

They're not underlined at least. ;)

@eric-milles
Copy link
Member

Actually, the local variable assignment case is not type inferencing / semantic highlighting any part of the anon. inner definition. This is what all anon. inners used to be like.

@eric-milles
Copy link
Member

Could you open a separate issue for the 2 anon. inners causing the second to be unprocessed?

@mauromol
Copy link
Author

mauromol commented Nov 10, 2017

Actually, the local variable assignment case is not type inferencing / semantic highlighting any part of the anon. inner definition. This is what all anon. inners used to be like.

Sorry, I think I didn't understand :-(
I'll open a separate issue though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants