Summary: | "Content Assist" does not complete normally on certain types | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Alexey Titov <a.m.titov> | ||||||
Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | major | ||||||||
Priority: | P3 | CC: | kentarou, Olivier_Thomann, satyam.kandula | ||||||
Version: | 3.6.1 | Flags: | Olivier_Thomann:
review+
|
||||||
Target Milestone: | 3.7 RC1 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Alexey Titov
2011-02-06 07:27:54 EST
Does this relate to JDT core? (In reply to comment #1) > Does this relate to JDT core? I think so. I believe the underlying problem comes from JDT/Core. Ayushman, please investigate. Thanks. This happens because of incorrect parsing of the binding key. org.eclipse.jdt.internal.core.util.BindingKeyParser.parseMethod() first parses the method signature and then parses the exceptions via the call to parseThrownExceptions(), and then the parsing of the type variables is done in org.eclipse.jdt.internal.core.util.BindingKeyParser.parse(boolean), line 647 after the parseMethod() has returned. Now the problem is that the parsing of the exceptions in parseThrownExceptions() is done by creating another parser but sharing the same scanner. So when the sub parser starts parsing, it finds the qualified name representing the signature and then when it tries to look for type variables, it also finds them since the signature looks like this: LEclipseTest$InvokerIF;.invoke<T::LEclipseTest$ArgIF;>(TT;)TT;|Ljava/lang/RuntimeException;:TT; The :TT; represents the type parameters and since they're immediately followed by the thrown exception, the parser moves the scanner ahead(though the type parameters are not relevant for this parser and it simply ignores it, the scanner cannot be reset back now). This way, when the control returns back to the original parser, and when it tries to look for the type variables of the method invoke(), it cannot find it since the scanner has already moved one place ahead. A possible fix is to make sure the parser does not look for type variable when parsing thrown exceptions, since exceptions cannot have type variables. I'm testing this fix. Created attachment 195119 [details]
proposed fix
Patch passes all tests
Created attachment 195191 [details]
proposed fix v1.0 + regression tests
This patch simply makes sure that the scanner doesnt look for tyoe variables while parsing thrown exceptions
Olivier, can you please review? Thanks! A UI test will have to be added to check that content assist doesn't throw an exception here. +1. The problem does come from the fact parsing the thrown exceptions also consuming the next type variable. The binding key resolver has lots of side-effects everywhere. Consuming the exception sets the type binding to be the exception type and the enclosing keybinding parser method binding is not remembered. So when scanning the type variable at the same time the exceptions are scanned, there is no match for the type variable binding name, because the type variable of the exception type are retrieved instead of the one from the method binding. So forcing to skip the type variable scanning while scanning the exception type seems to make sense. Once the exception is scanned, the binding key parser still needs to scan the type variable but in this case the method binding is there to return its type variables. Thanks Olivier. Released in HEAD for 3.7RC1 > A UI test will have to be added to check that content assist doesn't throw an > exception here. Added test via bug 345363 Verified for 3.7RC1 using I20110511-0800 |