Bug 92555

Summary: Code assist in Annotations suggests non-annotations
Product: [Eclipse Project] JDT Reporter: Erich Gamma <erich_gamma>
Component: CoreAssignee: David Audel <david_audel>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: philippe_mulet
Version: 3.1   
Target Milestone: 3.1 RC1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on:    
Bug Blocks: 102875    

Description Erich Gamma CLA 2005-04-25 04:48:31 EDT
In this scenario:

    public class FooTest {
	@<|>

code assist suggest FooTest as the only completion. This is not correct since
FooTest isn't annotation. In particular when you have code assist set to insert
single proposals automatically then the current behaviour is frustrating.
Comment 1 Philipe Mulet CLA 2005-04-25 06:32:22 EDT
I suspect we suggest any type, in case of member annotation types. But, we
should only do so when there is any such member type (or by default, we simply
do not give anything which isn't truly an annotation type, member annotation
types are unlikely to exist).
Comment 2 David Audel CLA 2005-04-25 07:34:24 EDT
Indeed we suggest any type, in case of member annotation type. We should propose
them only if they have a member type but it is not possible because to known if
they have one, we would need to resolve all proposed top level types and it
would be too costly to compute. This behavior is similar as exception completion
inside 'throws' and 'catch' clauses, is similar as interface completion inside
'extends' clause..
 
When the completion token is empty (as the test case of this bug report), only
enclosing types are proposed. In this specific case we could propose only
annotation.

In all cases the relevance of annotations is higher than other types.
Comment 3 Philipe Mulet CLA 2005-04-25 08:07:56 EDT
Right, but Erich's use case (in case of no prefix added) is likely exposing the
fact we do not go for an empty search for all type names; and then there is no
good more relevant match than the enclosing type.

From index search, we could figure member types by checking name info we get
back (member types have an enclosing type name). So we could only offer type
names which we now are acting as enclosing type names for other ?

Also in this specific scenario, all the info is at hand, since we are in the
context of the enclosing type we incorrectly suggest.

Comment 4 Erich Gamma CLA 2005-04-26 05:11:03 EDT
Not sure if it helps, but as user I rather receive no completions in this
scenario insteand of a bogus type name that I have to delete afterwards.
Comment 5 David Audel CLA 2005-05-18 09:31:04 EDT
Fixed.

Only annotations are proposed.

See bug 94965 comment 1.
Comment 6 Maxime Daniel CLA 2005-05-27 03:00:18 EDT
Verified on build I20050526-2000-win32.