Community
Participate
Working Groups
DESCRIPTION: The following code compiles with an error: package test; import org.eclipse.jdt.annotation.NonNullByDefault; @NonNullByDefault class Feature4<Q extends java.io.Serializable> { } @NonNullByDefault public class Test4 { public static <Q1 extends java.io.Serializable, F extends Feature4<Q1>> Q1[] getValues(F feature) { throw new RuntimeException(); } public static void f(Feature4<?> feature) { getValues(feature); } } getValues(feature); ^^^^^^^^^^^^^^^^^^ Null constraint mismatch: The type \'@NonNull Feature4<capture#of ?>\' is not a valid substitute for the type parameter \'F extends @NonNull Feature4<Q1 extends @NonNull Serializable>\' ANALYSIS: In CaptureBinding.initializeBounds, the null-related tagbits are not updated after invoking setSuperClass and setSuperinterfaces PATCH (via gerrit). Invokes TVB.evaluateNullAnnotations (with null as TypeParameter, which now means that now conflicts should be reported which should be ok as they should have been already reported on the actual type that was captured)
New Gerrit change created: https://git.eclipse.org/r/63399
(In reply to Till Brychcy from comment #0) > PATCH (via gerrit). > Invokes TVB.evaluateNullAnnotations (with null as TypeParameter, which now > means that now conflicts should be reported which should be ok as they > should have been already reported on the actual type that was captured) Can you please include a test case demonstrating this error reporting part?
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/63399 I'm too late to inspect the failure of hudson build #830. Did you have a look at that failure?
(In reply to Stephan Herrmann from comment #3) > (In reply to Eclipse Genie from comment #1) > > New Gerrit change created: https://git.eclipse.org/r/63399 > > I'm too late to inspect the failure of hudson build #830. Did you have a > look at that failure? I can't remember any failed tests so probably it was a Hudson problem ( or i have overlooked it). I have just pushed an updated change to trigger another build (and used the opportunity to correct the indentation in TVB)
(In reply to Till Brychcy from comment #4) > (In reply to Stephan Herrmann from comment #3) > > (In reply to Eclipse Genie from comment #1) > > > New Gerrit change created: https://git.eclipse.org/r/63399 > > > > I'm too late to inspect the failure of hudson build #830. Did you have a > > look at that failure? > > I can't remember any failed tests so probably it was a Hudson problem ( or i > have overlooked it). I have just pushed an updated change to trigger another > build (and used the opportunity to correct the indentation in TVB) Hudson signals: Regression org.eclipse.jdt.core.tests.compiler.regression.NullTypeAnnotationTest.testTypeBounds1 - 1.8 We no longer report this one: ---------- 3. ERROR in C.java (at line 17) la2.add(null); // ERR3 ^^^^ Null type mismatch: required '? extends @Nullable A' but the provided value is null ----------
i forgot, when testing locally i had tested with the fix for bug 484981 applied, which needs to be fixed first
(In reply to Stephan Herrmann from comment #2) > Can you please include a test case demonstrating this error reporting part? OK, I have prepared one (I found bug 485302 on the way). But let's fix bug 484981 first, before I push it to gerrit.
rebased patch; extended test case so it shows error reporting for conflicting annotations. But I have noted (bug 485708) that (unrelated to type bounds) null annotations on the wildcards are not checked against those on the corresponding type variables
Gerrit change https://git.eclipse.org/r/63399 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=00b69068488005cd0aaffb3b61aa3d99f98cc033
(In reply to Till Brychcy from comment #8) > rebased patch; extended test case so it shows error reporting for > conflicting annotations. thanks, the new test illustrates well what you mean by "should have been already reported on the actual type that was captured". It also shows an unavoidable error on the method invocation, since no type argument can match the contradictory type parameter. We my consider avoiding such secondary problems by clearing the contradiction, but that's not essential for this bug. Change has been merged for 4.6 M5, Thanks!
Verified for 4.6 M5 with build I20160119-0800
