Community
Participate
Working Groups
if I have "assertEquals(1,foo.bar)" in a unittest, and Foo does not currently have a field called "bar", I'm given a quick-fix choice to create such a field, but it always uses "Object" as the type. It should be able to tell better which assertEquals signature to use because of the constant as the first argument. At the least, it should offer the "picklist" of int and long as choices, rather than using Object.
The problem comes from the overloaded methods 'assertEquals'. jdt.core does the guessing of the method binding and it seems to select assertEquals(Object, Object). It could choose assertEquals(int, int), having a resolvable first argument: Then the quick fix would also create an 'int' Moving to jdt.core
Deferring post 3.1
bug 45155 is a dup of this
*** Bug 90400 has been marked as a duplicate of this bug. ***
*** Bug 97268 has been marked as a duplicate of this bug. ***
Olivier, this bug would be good thing to have fixed. Shouldn't be that hard.
*** Bug 107000 has been marked as a duplicate of this bug. ***
What binding do you expect?
My example (following in from 10700): I write: assertFalse(wibble()); Quickfix gives me a method with a return type of String, because there's a method: assertFalse(String, boolean) This doesn't compile. I want it to give me a return type of boolean, which would compile - there's a method: assertFalse(boolean)
Do you expect to get methods that are not visible? class Y { public static void assertFalse(String s, boolean b) {} private static void assertFalse(boolean b) {} } public class X { public static void main(String[] args) { Y.assertFalse(foo()); } } would you expect private static void assertFalse(boolean b) {} to be returned?
I guess I would first check for the same number of parameters, then visibility, then number of matching parameter types.
That's a hard example - as a user I'd probably rather get: public static void assertFalse(String s, boolean b) {} matched - neither will compile, but changing a line of code in a method feels like a smaller change than changing the public contract of a class - so it's closer to compiling.
Changed the heuristic to detect the best 'non-matching' method and fixed a problem in MessageSend (when an argument expression could not be resolved, all known arg types were thrown away). We're using the number of argument type and parameter type matches as well as the parameter count to decide. Let us know if there are some cases that need a different algorithm. Changed a few tests which picked up a poor method match and now get the best non-match.
Verified for 3.2 M3 using build I20051025-0800+JDT/Core v_618a
This bug doesn not seem to be correctly fixed: In the following example, 'assertFalse(x, y);' gets the binding of 'assertFalse(boolean b)'. See bug 116573. public class C { public void assertFalse(String s, boolean b) {} public void assertFalse(boolean b) {} public static void main(String[] args) { C.assertFalse(x, y); } }
I verified that the case in comment 9 works properly now. Kent, we might want to see how we can support other cases.
Martin, we have a new PR for that case. We do not need to reopen this one.
