Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] Incorrect handling of type variable bounds issued by capture conversion | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Philipe Mulet <philippe_mulet> | ||||||
| Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | david_audel, jerome_lanneluc, zorzella | ||||||
| Version: | 3.4 | Flags: | philippe_mulet:
pmc_approved+
|
||||||
| Target Milestone: | 3.3.2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 203318 | ||||||||
| Attachments: |
|
||||||||
(comment from spec lead) Consider the generic type class D<X extends A, Y extends X>... And the parameterized type D<?, ? super A> which capture-converts to D<#1 extends A super null, #2 extends #1 super A> This is legal because there is a possible instantiation for #1 and #2: A. Now consider the parameterized type D<?, ? extends A> which capture-converts to D<#1 extends A super null, #2 extends glb(A, #1) super null> Whatever #1 is, it extends A by its own definition, so glb(A, #1) is trivially well-formed and #2 can be inhabited. So I think D<?, ? extends A> is legal. The bound check is not truly performing a capture conversion, and rather tries to emulate it (to avoid creating captures on the fly). This results in slight differences in behavior. Investigating. Created attachment 78199 [details]
work in progress
This is not final. It breaks existing working scenarii.
Added GenericTypeTest#test1158-1162 Also see bug 159214 Created attachment 78381 [details] Proposed patch Alternate solution, better aligned with existing story. Basically, it doesn't induce more captures to be created, but simply tune the bound check test to better emulate the true capture. Note that this patch is combined with the changes for bug 159214 and bug 203318 since all these issues are intricated. Released for 3.4M2. Fixed *** Bug 179902 has been marked as a duplicate of this bug. *** Verified for 3.4M2 using build I20070918-0010 Released for 3.3.2 Fixed reopening to remove verify state Released for 3.3.2 Fixed Only adding Verified for 3.4M2 to the status whiteboard, since I believe this got lost. The compiler semantics near capture conversion need to be tuned to match the spec. Without these changes, we see quite many corner cases failing to compile properly or being rejected incorrectly, and numerous customers starting to notice it. +1 for 3.3.2 Verified for 3.3.2 using build M20080123-0800. |
Build 3.3.0 The following program shouldn't raise any compiler error: [X.java] class A {} class D<U extends A, V extends U> {} public class X { void foo() { D<?, ? super A> d1 = null; D<?, ? extends A> d2 = null; } } The compiler currently rejects d2 declaration: ---------- 1. ERROR in X.java (at line 6) D<?, ? extends A> d2 = null; ^^^^^^^^^^^ Bound mismatch: The type ? extends A is not a valid substitute for the bounded parameter <V extends U> of the type D<U,V> ----------