Community
Participate
Working Groups
Build ID: Build id: I20070323-1616 Steps To Reproduce: 1. Create a new Java File 2. Type import static java.lang.Math. 3. Try to select E or PI from the code completion popup Actual results: Nothing happens when you select either E or PI, works fine for methods. More information:
Reproduced with I20070516-1800.
The JDT/core completion proposal is correct. Move to JDT/Text.
This has been introduced in 3.3 M5 with the "Completion using favorite static imports" feature. Will have to see whether there's an easy fix for 3.3.
Two problems combined lead to the error: 1. the proposal returned by JDT Core is correct BUT for unknown reasons and in contraction to the following two scenarios: import static java.lang.Math.po<code assist> double pi= java.lang.Math.P<code assist> where the proposal is not fully qualified it returns a fully qualified proposal for the static field import. This "bug" can also be seen if you start 3.2.2 and look at the proposal list: pow is correctly shown with the simple name while PI is shown as 'java.lang.Math.PI' in the list. 2. JDT Text uses the display string to do the prefix validation which - while working in almost all cases - is clearly bogus and should be changed to use the replacement string. The reason why the display string got used are some special proposals like method declaration. David prepared a fix for 1. and I prepared a fix for 2 (see attachments). They both work (and tests pass) independently and together. When looking at the changes the first patch is clearly smaller and more local. The second patch is high risk at this point as JavaCompletionProposal not only has many subclasses but it is also directly used for several proposal kinds (e.g. param guessing, html completion etc.). Even though we have many tests there might be cases where code assist might get borken for cases even more important than import static field. I therefore suggest to only apply the JDT Core change for 3.3 and postpone the JDT Text change to early 3.4. Moving to JDT Core for comment and filed bug 188851 for the JDT Text issue.
Created attachment 68526 [details] Fix from David for 1.
Created attachment 68527 [details] Fix for 2.
Created attachment 68541 [details] Fix for 1 + update of regression tests
Perhaps the fix of comment 7 should be generalized for all kinds of proposals after 3.3. I don't see why type ref and method ref should be fully qualified in this case. I filed the bug 188876 for this issue.
Patch looks good and tests pass. Minor suggestion: I would simplify char[] completionName = field.name; completionName = CharOperation.concat(completionName, SEMICOLON); to char[] completionName = CharOperation.concat(field.name, SEMICOLON);
David's patch is OK for me. However, I have 2 remarks: 1) I'd remove unnecessary added empty lines (cosmetic) 2) line 2030 and follows: It took me a little time to understand that setSourceRange(...) was necessary in second if (!this....METHOD.NAME.REFERENCE)) block. I think it would be better to put all setSourceRange in the first if (!this...FIELD_REF)) block, because if the completion ignores fields, then source range would not be modified and set it with same value would not be necessary...
>2) line 2030 and follows: Yeah, that also caused a CPU spike in my brain ;-)
Created attachment 68565 [details] Better patch Patch with modifications suggested in comment 9 and comment 10.
Released for 3.3RC2. Test updated CompetionTests_1_5#test0072() -> test0074() CompetionTests_1_5#test0223()
Verified in I20070525-0010.
