Bug 507008 - [1.8][compiler][inference] Cannot infer type arguments with upper bound
Summary: [1.8][compiler][inference] Cannot infer type arguments with upper bound
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.7   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-03 17:22 EDT by Alex Iliev CLA
Modified: 2022-10-05 11:53 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Iliev CLA 2016-11-03 17:22:07 EDT
ecj reports the commented errors on the following code, source level 1.8. Tried with versions 4.6 and 4.7M3. Compiles fine under javac 7, 8 and 9.


public class Demo1
{
    interface MyFunction<A,B> {
        B apply(A a);
    }

    // Note: no problems if A doesn't have the upper bound

    private static class DelegatingFunction<A extends Number, B> implements MyFunction<A, B> {

        private final MyFunction<? super A, ? extends B> delegate;

        DelegatingFunction(MyFunction<? super A, ? extends B> delegate) {
            this.delegate = delegate;
        }

        public B apply(A t) {
            return this.delegate.apply(t);
        }
    }

    private static <A extends Number, B> DelegatingFunction<A, B>
    makeDelegatingFunction(MyFunction<? super A, ? extends B> delegate) {
        return new DelegatingFunction<A,B>(delegate);
    }


    public static <A extends Number, B> void constructor(MyFunction<? super A, ? extends B> delegate) {
        DelegatingFunction<A, B> f = new DelegatingFunction<>(delegate);
        // ERROR: Cannot infer type arguments for DelegatingFunction<>

        // workaround:
        f = new DelegatingFunction<A,B>(delegate);
    }

    public static <A extends Number, B> void genericMethod(MyFunction<? super A, ? extends B> delegate) {
        DelegatingFunction<A, B> f = makeDelegatingFunction(delegate);
        // ERROR: The method makeDelegatingFunction(MyFunction<? super A,? extends B>) in the type Demo1
        // is not applicable for the arguments (MyFunction<capture#13-of ? super A,capture#14-of ? extends B>)

        // workaround:
        f = Demo1.<A,B>makeDelegatingFunction(delegate);
    }
}
Comment 1 Jay Arthanareeswaran CLA 2016-11-04 00:32:55 EDT
Reproduced on master.
Comment 2 Sasikanth Bharadwaj CLA 2016-11-07 01:59:37 EST
The upper bound causes us to conclude that we have an inconsistent intersection during glb computation, and hence inference fails for the diamond. In ReferenceBinding.isConsistentIntersection, we have this line with the comment 

// when invoked during type inference we only want to check inconsistency among real types:
		if (current.isTypeVariable() || current.isWildcard() || !current.isProperType(true))
			continue;

In that case, we should probably apply the same rule to mostSpecific (which is taken as the first of the intersecting types, which is a CaptureBinding in this case)?
Comment 3 Eclipse Genie CLA 2019-03-08 15:22:27 EST
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.
Comment 4 Stephan Herrmann CLA 2019-03-10 15:28:11 EDT
Still relevant in 4.11RC2
Comment 5 Eclipse Genie CLA 2022-10-05 11:53:28 EDT
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.