Summary: | [1.5][compiler] Eclipse successfully compiles buggy code | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Ingo R. Homann <ingo.homann> |
Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> |
Status: | VERIFIED NOT_ECLIPSE | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | forax, gerpres, hendrik, moritz, Olivier_Thomann |
Version: | 3.2 | ||
Target Milestone: | 3.7 M5 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Ingo R. Homann
2005-12-19 03:41:27 EST
Don't set the target milestone. This indicates in which build the problem is fixed, not in which build the problem occurs. 1. I wonder if this isn't a bug in javac 2. When inferring, we find: <Object,List<T>>, where I would expect: <Object,List<Object>> 15.2.2.8: No expected return type (using assignment conversion). Additional constraint from type variable bounds: List<T> >> U 15.2.2.7: A >> F where A: List<T>, F: U First bullet says, if F = Tj --> Tj <: A is implied (p.457) i.e. U <: List<T> Constraints are resolved, see p.466 (15.2.2.8), and U = glb(List<T>) --> U = List<T> At the end, T remains unresolved; and thus get inferred to be Object. (the spec doesn't explicitly tell about need to substitute U inferred value List<T>, but presumably this is an omission). In the end, it should yield: T = Object, U = List<Object> In order to notice issue between List<T> and List<Object>, here is a testcase: class Foo { static <T, U extends java.util.List<T>> U foo() { return null; } } public class X { { String s = (String) Foo.foo(); } } Interestingly, the following variation doesn't seem handled well either by javac (replace List<T> with List<U>): class Foo { static <T, U extends java.util.List<U>> U foo() { return null; } } public class X { { String s = (String) Foo.foo(); } } but this time, it goes further in inference, failing only the bound check in the end; which makes me feel it has holes in this area. Now, our compiler doesn't quite handle this scenario either; yielding U = List<List<U>> which isn't much better. I feel the spec is incomplete when inference brings back types referring to original type variables (List<T> or List<U>). Either these are tolerated providing they are not resolving self references (List<T>) or they are all rejected for simplicity. Javac and spec bugs got confirmed, they should be: compiler: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369605 spec: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369608 defer post 3.2 Reviving *** Bug 156765 has been marked as a duplicate of this bug. *** *** Bug 156765 has been marked as a duplicate of this bug. *** *** Bug 158531 has been marked as a duplicate of this bug. *** *** Bug 174447 has been marked as a duplicate of this bug. *** Regression tests are: GenericTypeTest#test0880-0883 javac 1.7 doesn't report any error. Should not this be closed as NOT_ECLIPSE or INVALID? (In reply to comment #14) > javac 1.7 doesn't report any error. > Should not this be closed as NOT_ECLIPSE or INVALID? (In reply to comment #6) > Javac and spec bugs got confirmed, they should be: > compiler: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369605 > spec: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369608 Indeed. javac fixed the compiler bug in 7(b109). Resolving as NOT_ECLIPSE. Verified for 3.7M5 using I20110124-1800 |