Bugzilla – Full Text Bug Listing
| Summary: | Content Assist autocomplete broken within an array of anonymous classes instances | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Desislava Hristova <desi.hristova> | ||||
| Component: | Core | Assignee: | ANIRBAN CHAKRABORTY <anchakrk> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | amj87.iitr, andy.m.sheldon, daniel_megert, h.klene, jarthana, manoj.palat, mauromol, srikanth_sankaran, stephan.herrmann | ||||
| Version: | 3.8 | Flags: | srikanth_sankaran:
review+
|
||||
| Target Milestone: | 4.3 RC1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Thanks for the nice test case. Can reproduce using 3.8 M5. Similar to bug 306908, bug 311356, bug 318192, bug 336620 and bug 367612. Srikanth, that could be a nice polish item for M7. Here is another somewhat similar test case trying to initialize multiple fields in one go (instead of an array, though it shares the delimiting comma right after the anonymous inner class):
import java.awt.event.ActionEvent;
import javax.swing.AbstractAction;
import javax.swing.Action;
public class CodeCompletion {
private Action first = new AbstractAction() {
@Override
public void actionPerformed(ActionEvent e) {
// completed fine
someMethod();
}
}
, second = new AbstractAction() {
@Override
public void actionPerformed(ActionEvent e) {
// someM // -> A) no completion on methods
// sysout // -> B) would expand fine
}
}
// , third = new AbstractA // -> C) no completion on further initialization
;
protected void someMethod() {
}
}
Uncomment any one line at A) B) or C) and try code completion right before the marker // ->
This is not related to the other cases given in comment 1
Thanks for the test cases. All of these cases with anonymous class initializations are recovery related issues and will be investigated together. (In reply to comment #3) If you reverse the order, and put the declaration of someMethod() above the member variable declarations, then completion works correctly in "second" > private Action first = new AbstractAction() { > ... > , second = new AbstractAction() { > ... > protected void someMethod() { > } Is there any progress on this? We have found another problematic case much similar to this one, however I was not successful in extracting it in a simple test case. Using Eclipse 4.2.1, build id M20121107-1200, JDT 3.8.2.v20121002-144154-8-8nFqrFNOfwKDTWtsXHi6xm0834. (In reply to comment #6) > Is there any progress on this? We have found another problematic case much > similar to this one, however I was not successful in extracting it in a > simple test case. > Using Eclipse 4.2.1, build id M20121107-1200, JDT > 3.8.2.v20121002-144154-8-8nFqrFNOfwKDTWtsXHi6xm0834. I am afraid, no. The engineer who was assigned this bug is no longer with the team and there is none in the team who can spend time on this. But if anyone can provide a patch, that will be welcome. I see. But isn't this bug severe enough to put it in the 4.3 roadmap? When you have a complex class with hundreds of line of code where completion doesn't work because of this bug it's quite hard to work... :-( (In reply to comment #8) > I see. But isn't this bug severe enough to put it in the 4.3 roadmap? When > you have a complex class with hundreds of line of code where completion > doesn't work because of this bug it's quite hard to work... :-( I do understand your concern and the bug still has 4.3 as the target. We'll see if we can take it up during the next milestone. I'll take a look at this. My plan is to spend a bounded amount of time on this task to see if it can be addressed within that time. To see if this ever worked and if so what caused the breakage. If it looks more involved, it will have to wait till later as we are focused on Java 8 work and havinb a bit of catching up to do there. Assigning to Anirban as he is the code completion owner now. Created attachment 229939 [details]
Patch for the fix
Patch for the fix. Thanks
Patch looks safe. Released here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=4cf047ed8142f9c3048e153b5178c9b3d96df1fb. Anirban, please see if any of the bugs referenced in comment#1 get fixed by this patch, if so add suitable test cases and mark them as duplicates. I'll mark the present bug as resolved, but problem reported in comment#3 is not fixed by this patch. We should open a fresh issue for that and carry over the test case. Please CC the commenter from comment#3 on the new bug. Thanks. Hello, Bug 407979 is filed on the basis of comment 3. Bugs in comment 1 are existing, and I'll be happy to look into them if there are parties still interested in their solutions. Thanks Anirban Verified for RC1 Version: 4.3.0 Build id: I20130516-2200 |
Build Identifier: Version: 3.7.1 Build id: M20110909-1335 Autocomplete doesn't work when more then one anonymous classes' instances are instantiated in an array. See the code snippet below: // --------------- start of test snippet --------------- private Object[] items = new Object[] { new Object() { @Override public String toString() { // [1] Try completion here //super. return super.toString(); } }, // If I uncomment the line below the completion in [1] stops working //new Object() { } } ; // --------------- end of test snippet --------------- Reproducible: Always Steps to Reproduce: 1. Uncomment the //new Object() { } line 2. Try autocompletion in [1]