Community
Participate
Working Groups
It's just a detail, but the assignement errors are misplaced i think: import java.util.Vector; public class Test { private static Object getVector() { return new Vector(); } private static void test() { int i = getVector(); // the error is on "i" i = getVector(); // the error is on "getVector()" } } i believe the error should be on "=" for both lines.
Moving to JDT/Core.
Created attachment 24991 [details] Proposed fix I think to be consistent that both errors should be reported against getVector(). Here is a patch to fix the positions. Existing tests might need to be updated with this patch.
We would then report: ---------- 1. ERROR in d:\tests_sources\Test.java (at line 9) int i = getVector(); // the error is on "i" ^^^^^^^^^^^ Type mismatch: cannot convert from Object to int ---------- 2. ERROR in d:\tests_sources\Test.java (at line 10) i = getVector(); // the error is on "getVector()" ^^^^^^^^^^^ Type mismatch: cannot convert from Object to int ---------- 2 problems (2 errors)
(In reply to comment #2) > I think to be consistent that both errors should be reported against > getVector(). the call to getVector() is correct, it's the assignment wich is not. I really think the error should be on the operator.
I would agree to what Olivier is suggesting. Being consistent and blaming the assigned expression. Note that given the assignment, it feels like the expression is wrong as it doesn't match type expectation, and as the message tells: the RHS expression cannot be converted to LHS type. Olivier - pls perform the change in HEAD stream only.
(In reply to comment #5) > I would agree to what Olivier is suggesting. Being consistent and blaming the > assigned expression. > > Note that given the assignment, it feels like the expression is wrong as it > doesn't match type expectation, and as the message tells: the RHS expression > cannot be converted to LHS type. the right expression as itself has not any expectation to match, it's the conversion which is problematic. i think you think to much about the implementation of the type checker. If you didn't know how it works, you would agree with the problematic assignement point of view.
Olivier, could you wait with releasing this fix until Martin is back? It causes failing test cases in LocalCorrectionsQuickFixTest and TypeMismatchQuickFixTests. Furthermore, I'm not sure whether blaming the expression is really the right solution. If you consider the same error for method invocations, then the range is currently not on the expression either: static void takeInt(int i) {} private static void test() { takeInt(getVector()); // the error is on "takeInt" }
Markus, I'll wait till Martin is back. The problem is getVector() in the context of an assignment to an int local variable. Blaming the getVector() from not being compatible with an int is fine. The only concern we have here is not being consistent as you mentionned in the first comment. The method invocation should also be investigated.
I'm back, let me know when you release the change.
Ok, probably tomorrow. The fix would be released only in HEAD for now.
Martin, I am ready to release. Sorry for the delay.
Created attachment 25746 [details] Regression tests updated
Created attachment 25747 [details] Regression tests updated For compiler tests.
Move to 3.2M2 as this requires more work on the UI side (quick fix implementation).
(In reply to comment #6) > the right expression as itself has not any expectation to match, it's the > conversion which is problematic. > > i think you think to much about the implementation of the type checker. If you > didn't know how it works, you would agree with the problematic assignement point > of view. What is wrong is the type of the initializer expression in the context of an assignment. It is perfect fine to report the error on the expression. I don't see why the operator should be blamed.
fixed in JDT UI to work with old and new problem locations. Will go in the 20050817 I-rebuild.
sorry, didnt go into 20050817 I-rebuild. Just HEAD.
Fixed and released in HEAD. Updated existing tests.
Verified using I20050920-0010 for 3.2M2
