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

Fully qualified type name inserted in private final field declaration instead of import + simple name (disregarding workspace preference) #873

Open
mauromol opened this issue Apr 16, 2019 · 5 comments
Labels
Milestone

Comments

@mauromol
Copy link

Variation of #866.

Consider this class:

package test50

class Test50 {
	
	String foo
	
	private final TreeNode|
}

Invoke code assist at "|" and choose javax.swing.tree.TreeNode.
Once again, the fully qualified name is inserted instead of the import declaration.

@eric-milles eric-milles self-assigned this Apr 16, 2019
@eric-milles eric-milles added this to the v3.4.0 milestone Apr 16, 2019
@eric-milles
Copy link
Member

Different path through the parser. I'll see what I can do...

@eric-milles
Copy link
Member

eric-milles commented Apr 16, 2019

The trouble is, Groovy considers this a complete field declaration:

@groovy.transform.ToString(includeFields=true)
class C {
  protected field
}

def cee = new C(field: 'value')

println cee​

http://docs.groovy-lang.org/latest/html/documentation/#fields

@mauromol
Copy link
Author

But isn't "final" some kind of reserved word?

@eric-milles
Copy link
Member

The type is optional. So the parser interprets "private final TreeNode" as a field named "TreeNode" of type Object.

@mauromol
Copy link
Author

I keep on hitting this problem. The presence of private (even without final) is sufficient to trigger it. I understand the cause (the parser interprets "private TreeNode" as a field named "TreeNode"), but once content assist is triggered and confirmed, why should it ignore the option to insert the import statement instead of the FQN? After all, if the insertion is performed, in some way the tools is recognizing TreeNode as a type at that time...

@eric-milles eric-milles removed their assignment Oct 25, 2019
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