Community
Participate
Working Groups
org.eclipse.jdt.core.tests.compiler.parser.CompletionParserTest#testEA_1 fails. Also many Completion tests near the catch clause fail.
Created attachment 189456 [details] Proposed patch
Ayush, Can you please review the patch and give your comments.
Ayush, I have released the fix on the BETA_JAVA7 branch, but please do review the changes so that I can incorporate the changes.
The patch looks good. However, just to document some small concerns, I noticed a few things in checkCatchClause(), that are not part of the new consumeDisjunctive...() method. 1) The condition "if ((topKnownElementKind(COMPLETION_OR_ASSIST_PARSER) == K_BETWEEN_CATCH_AND_RIGHT_PAREN) && this.identifierPtr > -1) { // NB: if the cursor is on the variable, then it has been reduced (so identifierPtr is -1), // thus this can only be a completion on the type of the catch clause" infers completion on type of catch clause only when this.identifierPtr>-1. In the new scenario, identifierPtr is -1. 2) I'm not sure what the line this.lastCheckPoint = this.assistNode.sourceEnd + 1; was for in the checkCatchClause() method. Do you have any idea?
(In reply to comment #4) > 1) The condition > "if ((topKnownElementKind(COMPLETION_OR_ASSIST_PARSER) == > K_BETWEEN_CATCH_AND_RIGHT_PAREN) && this.identifierPtr > -1) { > // NB: if the cursor is on the variable, then it has been reduced (so > identifierPtr is -1), > // thus this can only be a completion on the type of the catch clause" > > infers completion on type of catch clause only when this.identifierPtr>-1. In > the new scenario, identifierPtr is -1. The getTypeReference() called from this code needs this identifier to create the appropriate reference. Now, the getTypeReference gets called from the parser directly which would have had the identifier on the stack at that moment. > > 2) I'm not sure what the line this.lastCheckPoint = this.assistNode.sourceEnd + > 1; > was for in the checkCatchClause() method. Do you have any idea? Actually getTypeReference() is actually updating the lastCheckPoint and this doesn't look necessary.
Had forgotten to +1 this. So doing it now
Verified using Eclipse Java 7 Support(Beta) feature patch v20110623-0900.