Bugzilla – Full Text Bug Listing
| Summary: | [assist] don't rank java.lang types lower if a simple name duplicate exists | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Tom Hofmann <eclipse> | ||||||
| Component: | Core | Assignee: | David Audel <david_audel> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | eclipse.dserodio | ||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | 3.2 M3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 27513 [details]
CompletionEngine.java.diff
The patch only requires qualification for a proposal with a duplicate simple
name if the the proposed type is not in the "java.lang" package.
The bug is more general. If a type has an on demand import (java.lang has an implicit on demand import) and there is another type with the same simple name but without an on demand import, then CompletionEngine qualify both types. Only the type without import should be qualified. Created attachment 27853 [details]
more general patch
Fix released and test added in HEAD. CompletionTests#testCompletionImportedType1() -> testCompletionImportedType5() Verified for 3.2 M3 using build I20051025-0800+JDT/Core v_618a |
3.2 M2 TYPE_REF proposal ranking... I noticed that String is ranked lower than StringBuffer and (worse!) StringIndexOutOfBoundsException in the following situation (| = caret): class X { St| } which is especially unlucky in this situation: class X { CharSequence cs= St| } Since I cannot refine the proposal list any further by typing in more characters (since String is a prefix of the higher-ranked proposals), this means the only way to select the proposal is by using the arrow keys / mouse. -- The reason why String is ranked lower is that there are other types in the type universe that have the same simple name, which causes the AcceptedType.mustBeQualified flag to come true. This seems "unjust" for java.lang types. Types that do not require imports should be treated almost like already imported types.