Community
Participate
Working Groups
There's a regression regarding Diamond operators, lambdas, and interfaces. The following java code does not compile in Eclipse Neon (4.6) but compiles and rusn perfectly in Luna (4.4.2) and javac: import java.util.function.Function; public class Test { public static void main(String[] args) { foo(new Data(), new FunctionContainerImpl<>(a -> "test")); } public static <A extends Data> void foo(A data, FunctionContainer<A> container) { System.out.println(container.get(data, data)); } interface FunctionContainer<A extends Data> { boolean get(A a, A b); } public static class Data { } public static class FunctionContainerImpl<A extends Data, T extends Comparable<T>> implements FunctionContainer<A> { private Function<A, T> getComparable; public FunctionContainerImpl(Function<A, T> getComparable) { this.getComparable = getComparable; } @Override public boolean get(A a, A b) { return getComparable.apply(a).compareTo(getComparable.apply(b)) == 0; } } } Error in eclipse says: Type mismatch: cannot convert from String to Comparable<Comparable<T>> It should be Comparable<T>, not Comparable<Comparable<T>>.
As of 4.7 M3 this is no longer an issue. Please try with a newer build. Now I will try and find out which commit fixed this.
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.
(In reply to Jay Arthanareeswaran from comment #1) > As of 4.7 M3 this is no longer an issue. Please try with a newer build. Sorry, but no: ecj rejects all the through today's HEAD. The problem results from our optimization in bug 448794, which conflicts with the code controlled by SHOULD_WORKAROUND_BUG_JDK_8153748: we where caching a result even when inner inference was not yet ready.
New Gerrit change created: https://git.eclipse.org/r/139933
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/139933 WIP The current issue can indeed be resolved by avoiding calls to registerResult() when inner is not ready. Unfortunately, this causes 13 failures in GRT_18 alone. Of those I started to debug test499351_extra2(), and observed that now invocation type inference for Collectors.toMap() *fails*. Need to dig deeper, to find out why.
Further into the rabbit whole, analyzing the failure in test499351_extra2() caused by the WIP change: - calling infCtx18.forwardResults() is necessary to replace inner PolyPGMB with a regular PGMB, which avoids inner inference during resolvePolyExpressionArguments() - if, OTOH, inner inference is triggered, it fails during incorporation of capture bounds, in this rule of 18.3.2: "If Ai is a wildcard of the form ?: - αi = R implies the bound false" - one of the relevant bounds is created in IC18, in the branch that should never be entered due to "if (!tmpBoundSet.hasCaptureBound(variableSet))", which is without effect since bug 448793 => It seems, that forwardResults() just prevents an inference that otherwise would fail for reasons that appear be beyond our powers. Keeping this current bug seems to be the lesser evil. Will drop a few more details into bug 448793 and then stop investigating.
