Community
Participate
Working Groups
In a number of situations content assist fails because the GNUCPPSourceParser does not return a completion node. All situations are reproducable through junit tests in package org.eclipse.cdt.ui.tests.text.contentassist2. The list below gives the specific classes which fail, and a short description of the situation. The exact C source code which leads up to the problem can of course be retrieved from the given classes. This bug may have to be split into several entries if various causes are found for the failure. From my current perspective it's the GNUCPPSourceParser as a blackbox which does not deliver a completion node. So here is the list: Completion in an argument list: void foo( ??? - CompletionTest_ArgumentType_NoPrefix - CompletionTest_ArgumentType_NoPrefix2 Completion where a class definition would be appropriate: class X : ??? - CompletionTest_ClassReference_NoPrefix exception to be caught: catch ( ??? - CompletionTest_ExceptionReference_NoPrefix Class field type specifier: class A { ??? } - CompletionTest_FieldType_NoPrefix - CompletionTest_FieldType_NoPrefix2 where a macro reference would be appropriate: #ifdef ??? - CompletionTest_MacroRef_NoPrefix - CompletionTest_MacroRef_Prefix where a namespace reference would be appropriate: using namespace ??? - CompletionTest_NamespaceRef_NoPrefix where operator new needs a type specification: aClass myClass = new ??? - CompletionTest_NewTypeReference_NoPrefix Starting a statement in a method context: void anotherClass::anotherMethod() { ??? } - CompletionTest_SingleName_Method_NoPrefix left hand side of an assignment in a function context void foo(int x){ int y = ??? } - CompletionTest_SingleName_NoPrefix Starting a statement in a global context: - CompletionTest_VariableType_NoPrefix
Created attachment 57541 [details] proposed patch The source of the problem is actually the scanner for the GNUCPPSourceParser. Once the scanner reaches the last character to be processed for the completion it creates a COMPLETION token if it is in the process of scanning an identifier. If the parser looks past the COMPLETION token, it will only find EOC (End Of Completion) tokens. The problem occurs if an identifier is not being scanned when the last character is reached. Then, an EOC token is returned. The GNUCPPCompletionParser, however, still requires a COMPLETION token to properly create a completion node. So simply returning a COMPLETION token instead should do the job. A couple of small changes were also made in GNUCPPSourceParser to handle COMPLETION tokens during the parsing of base specifiers. The patch fixes completion node creation (but not necessarily completion proposal generation) for the following cases: - CompletionTest_ArgumentType_NoPrefix - CompletionTest_ArgumentType_NoPrefix2 - CompletionTest_ClassReference_NoPrefix - CompletionTest_ExceptionReference_NoPrefix - CompletionTest_FieldType_NoPrefix - CompletionTest_FieldType_NoPrefix2 - CompletionTest_NamespaceRef_NoPrefix - CompletionTest_NewTypeReference_NoPrefix - CompletionTest_SingleName_Method_NoPrefix - CompletionTest_SingleName_NoPrefix - CompletionTest_VariableType_NoPrefix The following cases still do not produce completion nodes: - CompletionTest_MacroRef_NoPrefix - CompletionTest_MacroRef_Prefix However, this is because the GNUCPPSourceParser is not responsible for preprocessor directives. In fact, there is no completion processing at all for preprocessor directives, which is another problem altogether.
Great! A tiny patch but a big step forward for code completion.
I have applied the patch and updated the tests. Together with the patch for bug 169480 most of those tests actually succeed.
(In reply to comment #3) > I have applied the patch and updated the tests. > Together with the patch for bug 169480 most of those tests actually succeed. This is _impressive_, and I am quite happy that my labor in preparing this report was not in vain ... Anton, will this be in 3.1.2?
Although the patch is quite "harmless", I'd rather not given that 3.1.2 release date is not far ahead.