Community
Participate
Working Groups
Build 3.0RC1 Any selection occurring inside a declaration (type, field or method) is currently relying on the resolved binding for these, so as to match them in the source element in the end. It should only infer the nature of the selection, and then based on its source location find out the proper corresponding element.
David - pls investigate how much work this would be, and assess feasibility for RC2. If too risky we should defer it.
Created attachment 11926 [details] patch proposal
Created attachment 11927 [details] java model test update
This patch: - avoid to resolve binding when a declaration is selected. - select the correct duplicate type declaration, method declaration or field declaration
This patch fix also bug 65948 bug 65260 New supported cases are - selection of duplicate method declaration with paramater class X { void foo(X x){} void foo(X x){} } - selection of duplicate field declaration class X { int bar; int bar; } - selection of duplicate type declaration public class X { } class X { } - selection of a declaration inside a duplicate type declaration public class X { } class X { void foo(){} } - selection of a method method declaration with unresolved parameters class X { void foo(Unresolved x) {} } - selection of a method method declaration with syntax error inside parameters class X { void foo(X a, X){} }
CodeSelect is used intensively. Performance wise this is significantly speeding up resolution of declaration selections. In addition, it addresses elegantly issues where types could not be resolved (we don't care any longer as selection is matching with source model anyway). I would vote to get it addressed for RC3. Dirk - what is your take ?
Philippe, what are the side effects of this? - do we get more/less resolved declarations or is this simply a performace optimization - what happens if the element doesn't exist?. Will we now get a IJavaElement handle which doesn't exist, whereas in the past we got nothing (e.g an empty array from code resolve).
It's not only a performance fix. We get more declarations. All cases in comment 5 did not work before (nothing returned or enclosing type returned instead of method declaration). These new results are only existing elements.
This patch also fix a part of bug 65936 public class A { public static A show( int i ) { return new A(); } public void show( int i ) { } } If you rename the first method 'show' with Refactor->Rename (or Alt+Shift+R) the result is good. But if you rename the second method instead, there is an org.eclipse.jdt.internal.corext.Assert$AssertionFailedException: assertion failed; second condition. There is another problem with the following test case. public class A { public void show( int i ) { } public void show( int i ) { } } If you rename the first method with Refactor->Rename then the second method and the first method will be renamed.
The AssertionFailedException can occur without this patch and with another test case. see bug 67260.
David: pls provide perf stats on this fix.
With a small test case (a class with one method declaration) codeSelect is 18% faster (without patch 0,97 ms and with patch 0,79 ms) With a more complex test case (Parser.java) codeSelect is 50% faster (without patch 26,2 ms and with patch 13,1 ms)
Approved by Dirk
Reviewed the change. Pls release it.
Fixed and regression tests added.
*** Bug 65948 has been marked as a duplicate of this bug. ***
*** Bug 65260 has been marked as a duplicate of this bug. ***
Verified for 3.0RC3 I200406180800
