Community
Participate
Working Groups
The following code is accepted by eclipse while javac rejects it with an incompatible types error interface I2 {} interface I3 {} class Y<T extends X> { T t; } class W<R extends Y<?>> { R r; W(R r) { this.r = r; } } public class X { void foo(W<Y<? extends I2>> wyi2) { var vwyz = wyi2.r; W<Y<X>> wyx = new W<>(new Y<X>()); vwyz = wyx.r; // javac complains here } }
The reason is that TypeBinding.isTypeArgumentContainedBy() returns true for an ITB18 if the type argument is equal to *any* of the constituent types of the ITB18. This looks wrong. Removing that check results in the expected error, but obviously that needs a lot more scrutiny
The original code from comment 443596 comment 0 (which introduced this change in TypeBinding.iTACB) is now rejected by javac but accepted by eclipse, which kind of supports the argument that the said code is not doing the right thing. The main reason for this code is cited to be ICTB not being hooked into compatibility checks. After bug 527554 and bug 532349, it kind of is hooked now (and in the right way, I dare to presume), so I guess that obsoletes the need for the change in TypeBinding.iTACB pertaining to intersection types.
(In reply to comment #2) > The original code from comment 443596 comment 0 (which introduced this change in > TypeBinding.iTACB) is now rejected by javac but accepted by eclipse, which kind > of supports the argument that the said code is not doing the right thing. The > main reason for this code is cited to be ICTB not being hooked into > compatibility checks. After bug 527554 and bug 532349, it kind of is hooked now > (and in the right way, I dare to presume), so I guess that obsoletes the need > for the change in TypeBinding.iTACB pertaining to intersection types. but the resulting test failures tell me it does not. 6 tests fail altogether from GTT, GRT and GRT_1_8 which need to be analyzed before making a call on this
Stephan/Jesper, this is the bug I had in mind when I earlier contacted you offline with a testcase. But unlike what I had thought earlier, this bug is about ECJ accepting an invalid code. But what I have now is the opposite, but also falls in the same area: class A<E> { A(E t) {} } class B<T extends Iterable<? super A>> { void meth(T t) { for (var a : t) { a = new Object(); // Error reported by ECJ } } } public class TypeInferTest2 { public static <T> A<? super T> m1(T t) { return null; } public static <U> A<? super A<? extends U>> m2(A<? super U> u) { return null; } public static void foo() { Long val = (Long) 40L; A<?> a = new A(val); var val2 = m2(m1(a)); A<?> val3 = val2; val2 = val3; // Error reported by ECJ } } In the former case LHS is computed to be of type ? super A#RAW while in the latter case it is A<? super A<? extends A<capture#1-of ?>>> Jesper says he may not be look at this immediately, but will get to it after couple of weeks.
Honestly, I simply don't have overview of how type bounds and raw types interact to do anything remotely useful with this bug, so I'll have to pass.
A wild guess concerning case 1 (comment 4): javac could be seeing that var-inference involves a raw type and thus falls back to inferring j.l.Object. Chap.18 type inference as smth like this if unchecked conversion is involved. Does var-inference have a similar kill switch? Or, is there a rule stating that lower bounds should generally be dropped in var-inference, because they don't allow access to any features of the variable? I don't have the spec for 'var' at hand. -------------- For the second case the full message is: Type mismatch: cannot convert from A<capture#7-of ?> to A<? super A<? extends A<capture#1-of ?>>> A capture as a variable type is unusual. Without var this would not be denotable. I can't think of a type that would be assignable to a capture. Also a mix of wildcards and captures in the RHS is unusual. --------------- Both look quite different from the case on comment 0, though.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
