Community
Participate
Working Groups
Using HEAD, compiling the code reports a missing implementation error in the compiler. import java.util.HashMap; import java.util.Map; public class X { private static Map<String, Zork> map = new HashMap<String, X>(); public static X foo(String s) { return map.get(s); } } reports: ---------- 1. ERROR in D:\tests_sources\X.java (at line 5) private static Map<String, Zork> map = new HashMap<String, X>(); ^^^^ Zork cannot be resolved to a type ---------- 2. ERROR in D:\tests_sources\X.java (at line 8) return map.get(s); ^^^ Missing code implementation in the compiler ---------- 2 problems (2 errors)[compiled 9 lines in 422 ms: 21.3 lines/s] The second error should not be reported. This comes from the fact that the type of the field cannot be resolved.
I'll investigate.
If I change the ParameterizedTypeBinding implementation of problemId() to return ProblemReasons.NotFound in the case the inner type is a binary type binding, then some tests inside: org.eclipse.jdt.core.tests.model.CompletionTests_1_5 org.eclipse.jdt.core.tests.model.CompletionWithMissingTypesTests_1_5 org.eclipse.jdt.core.tests.dom.ASTConverter15Test are failing. It is possible to pass all the tests by changing the org.eclipse.jdt.internal.compiler.problem.ProblemReporter.invalidType(ASTNode, TypeBinding) implementation to test for the tagbit TagBits.HasMissingType, but this looks more like a hack. I'll talk with David when he is back from vacations.
Created attachment 110000 [details] Regression test
Released disabled regression test org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#_test1369
David, If I report an type not found error when a parameterized type binding has a arguments that cannot be resolved, some tests fail in the completion 1.5 tests. I believe reporting this error code is the right thing to do. Could you please look at this and tell me if you have a different way to solve the completion issues?
Here is another case that may be related: class X { A<E> a; // E is undefined on purpose X() { a = new A<E>(); } // causes Missing code implementation... } class A<E> {}
Created attachment 112086 [details] Proposed fix + regression tests
Created attachment 112103 [details] Proposed fix + regression tests Philippe, please review.
Philippe, I release the code as it improves the current behavior. We still have time to tune it if necessary. Released for 3.5M2. Added regression tests in org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#test1368 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#test1369
The fix looks good.
Please also backport for 3.4.2 inclusion. This behavior is just exposing a hole in our support for missing types (since 3.4) and is somewhat a regression over 3.3 where the error message was more understandable: 3.3 BEHAVIOR=================================================================== Eclipse Java Compiler 0.791_R33x, 3.3.2, Copyright IBM Corp 2000, 2008. All rights reserved. [compiled 315 lines in 454 ms: 693.8 lines/s] ---------- 1. ERROR in X.java (at line 4) private static Map<String, Zork> map = new HashMap<String, X>(); ^^^^ Zork cannot be resolved to a type ---------- 2. ERROR in X.java (at line 6) return map.get(s); ^^^ map cannot be resolved ---------- 2 problems (2 errors) 3.4 BEHAVIOR=================================================================== Eclipse Java Compiler 0.874, 3.4.0, Copyright IBM Corp 2000, 2008. All rights reserved. [compiled 315 lines in 422 ms: 746.4 lines/s] ---------- 1. ERROR in X.java (at line 4) private static Map<String, Zork> map = new HashMap<String, X>(); ^^^^ Zork cannot be resolved to a type ---------- 2. ERROR in X.java (at line 6) return map.get(s); ^^^ Missing code implementation in the compiler ---------- 2 problems (2 errors)
Verified for 3.5M2 using build I20080918-0100.
Unfortunately, it seems that we missed to backport this fix to 3.4.2 stream. So, move the target to 3.5M2 and set it as verified for this stream...
Too bad ! Too late for inclusion in 3.4.2. Technically, it is not super critical as it results in wrong error message being surfaced. The poor error message looks scary, but still localized. Olivier - could you still prepare a 3.4.x patch for releasing to the branch post 3.4.2 (in case someone needs it).
Created attachment 125135 [details] Patch for 3.4 maintenance branch Philippe, +1 to release it in 3.4 maintenance stream ?
