Community
Participate
Working Groups
BETA_JAVA8: interface I { X [][][] copy (int x); } public class X { public static void main(String[] args) { I i = X[][][]::new; X[][][] x = i.copy(136); System.out.println(x.length); | // - no completion proposals here. } }
I'm working on this.
Created attachment 230924 [details] Applicable regression clean patch Applicable regression clean patch
Anirban, Why won't similar changes be required in consumeReferenceExpressionGenericTypeForm ? Won't we leaving the data structures dirty by not popping K_BETWEEN_NEW_AND_LEFT_BRACKET at the right point ? I wonder if consumeIdentifierOrNew is a better place to pop this. Alternately, if we don't push K_BETWEEN_NEW_AND_LEFT_BRACKET at all for reference expressions, it would be better - after all we are NOT between new and [
(In reply to comment #3) > Anirban, Why won't similar changes be required in > consumeReferenceExpressionGenericTypeForm ? Won't we leaving the > data structures dirty by not popping K_BETWEEN_NEW_AND_LEFT_BRACKET at > the right point ? > > I wonder if consumeIdentifierOrNew is a better place to pop this. > > Alternately, if we don't push K_BETWEEN_NEW_AND_LEFT_BRACKET at all > for reference expressions, it would be better - after all we are NOT > between new and [ Hello, I'll re-submit a patch, in short time, by removing the token at after IdentifierOrNew is seen (and, ofcourse, ensuring the sanity of the patch). Thanks Anirban
Created attachment 231044 [details] Patch after accommodating the review comments Patch after accommodating the review comments. K_BETWEEN_NEW_AND_LEFT_BRACKET is popped at consumeIdentifierOrNew.
Created attachment 231428 [details] Patch restraining irrelevant activities in reference expression scope Patch restraining irrelevant activities in reference expression scope
I made some simplifications: - Renamed inReferenceExpressionScope to be inReferenceExpression since these constructs do not introduce a scope per se. - Localized the management of this state variable to CompletionParser. There is no need for the main parser to be involved in what is only a completion issue. - Centralized the state management by introducing a new override in CompletionParser rather than have the state managed in 4 different places. - Restructured the switch just a little bit to minimize the diffs and have the delta stand out. Released fix and test here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=f0cc0529135fe43e5b6252dca937651f0a04d49c Thanks Anirban.