Improve code assist in field declaration

[mauromol]

Consider the following:

package test50

class Test50 {
	
	String foo
	
	List|
}

Invoke code assist at "|". This is what I see:

• the most obvious suggestions (those that start with List, or even exact matches) are shown below other suggestions that apparently are not relevant; this class is small, so it's not a big issue, a normal class has many fields and methods, so relevant suggestions are lost; this is very annoying
• if I choose "java.awt.List" and hit enter, no import declaration is added

Consider this slight variation:

package test50

class Test50 {
	
	String foo
	
	TreeNode|
}

and suppose I want to choose javax.swing.tree.TreeNode: the fully qualified class name is inserted, instead of keeping just TreeNode and adding a new import. This happens although I have the Code Assist option "Add import instead of qualified name" checked.

[eric-milles]

There is definitely a bug in GroovyProposalTypeSearchRequestor. This block tries to determine if an import (or qualifier) is required. Since it has already seen "java.util.List", it fails to make a correct determination for "java.awt.List".

                // check for star import if expression is not qualified and type name not seen already
                if (!qualified && onDemandImports != null && !onDemandFound.containsKey(simpleTypeName)) {
                    char[] qualifier = packageName;
                    if (enclosingTypeNames != null && enclosingTypeNames.length > 0) {
                        qualifier = CharOperation.concatWith(packageName, type.enclosingTypeNames, '.');
                    }

                    for (char[] importName : onDemandImports) {
                        if (CharOperation.equals(qualifier, importName)) {
                            onDemandFound.put(simpleTypeName, type);
                            continue next;
                        }
                    }

                    type.mustBeQualified = true;
                }
                proposals.add(proposeType(type));
            }

[eric-milles]

The build server went out of service. I'll update when a new snapshot is available,

[eric-milles]

Import/qualifier insertion is ready to test.

[mauromol]

Now if I choose the suggestion for "java.awt.List" the editor inserts the fully qualified java.awt.List. However I still don't understand why it inserts the fully qualified name if I have the option "Add import instead of qualified name" checked. In all the other parts (for instance if I'm defining a local variable) Greclipse correctly adds the import and keeps the non-qualified name, instead.

Also, please please have a look at the suggestion relevance issue...

[eric-milles]

I'm not sure why you get the fully-qualified name. I get the import in my testing.

The relevance is part of #674. Types and packages get a very low base relevance score. So the boosting for prefix match does not impact them much.

[mauromol]

I'm not sure why you get the fully-qualified name. I get the import in my testing.

I don't know. As I said, it's the only place where this happens. And it happens on at least two different workspaces that I don't think have anything in common.

The relevance is part of #674. Types and packages get a very low base relevance score. So the boosting for prefix match does not impact them much.

Ok, but consider that, in this specific case, there are some aggravating factors:

• it's a place where (most probably) only types make sense (other suggestions are related to new code generation)
• if I really want to have new code generation at this point, there should be some relation with what I have typed (why "getFoo()"/"setFoo()" are suggested after I typed "List"?? They have nothing in common)
• many of the other suggestions given are simply wrong and don't do anything; see this example:

getList()/setList() are simply wrong. And even if I wanted to any reason to select getFoo()/setFoo(), after I press Enter nothing occurs (the suggestion list simply gets closed)

• if I type "Lis", then Ctrl+Space, then add "t", at this point the suggestion list is coherent (all irrelevant/wrong suggestions are removed); yes, the order of suggestions is still to be improved (as described in each on a collection is not enough promoted on content assist #674) and yes, suggestions are not recomputed (as I outlined in Inconsistent list of suggestions when trying to complete List.with #411), but these are separate issues

So I think there are some additional problems here besides the need for a better suggestion order/update.

[eric-milles]

True, that's a bunch of poor suggestions. I think parser recovery is creating a field with name "List" so that content assist works at this location. I can look into the filtering for the new method proposals; they all seem like they should be filtered in this case.

[eric-milles]

Ready for re-test.