Autocomplete / proposals incorrect when followed by variable declaration

[ssadedin]

When the next statement is a variable declaration, autocomplete on the previous statement seems to be generated from the surrounding class context instead of the correct object. It is probably easiest to explain with a screenshot:

In this example, I expect to see proposals for the String and GString types, but actually observed behavior is I see proposals for the surrounding class (CompletionProblem).

If instead I change the code to instead use a different statement (eg: assignment) then I see the correct autocomplete proposals:

[eric-milles]

Thanks for the submission. In this case, the "hello".\n\tdef forms a complete property expression. Then the parser starts looking at a = 23 and says that can't be part of the command expression (that starts with println) and it can't be the start of a new statement/expression since there is not a sufficient separator (newline or semicolon).

I'll see what I can do with the parser; it's a bit tricky in this case.

[eric-milles]

Ready to test for Eclipse 4.15+

[ssadedin]

Thanks @eric-milles! nice work. I will look out for the next snapshot build and try it out.

[ssadedin]

Tested snapshot build and confirmed fix works. Thanks!

[ssadedin]

NB: I'm not sure if it's a regression due to this change or something else, but I've found the snapshot build seems to have a problem with static imports:

I'm particularly seeing it where the static import is from a class that is imported by default (because it's in the same package, or a default language import like java.util.*.

Feel free to close if this known / dupe / unlrelated, but thought it worth mentioning in case it's related to this fix.

[eric-milles]

I disabled that behavior here 70655e8

I'm curious to know how useful it is vs. spelling out the fully-qualified types. It's a real performance hit for files with a large number of import statements and confusing for newcomers that imports can depend on other imports (often hidden ones), which is something Java does not support.

[ssadedin]

Thanks @eric-milles - just to follow up on the static imports. It's not a inconvenient at all in terms of my own code (trival to fix) but I guess the issue will be that if

import static Math.abs

is valid Groovy in general, then you'll have projects from outside groovy-eclipse that use it and they'll show errors inside groovy-eclipse. I'm not sure how common it is use this form of static import. Given that it isn't valid Java it's probably very rare and I'd probably prefer a big performance improvement over supporting it.