Compilation error with Eclipse 4.39 not with javac or Eclipse 4.38

[RoiSoleil]

This code doesn't compile in Eclipse 4.39

package repro;

import java.util.List;

public class A {

    public static void main(String[] args) {
        System.out.println(List.of(BusinessExtractBuilder.create())); // Error here
    }

    public static class BusinessExtractBuilder<T> {

        public static <U extends BusinessExtractBuilder<U>> U create() {
            return null;
        }

    }

}

I get this :

- Type mismatch: cannot convert from A.BusinessExtractBuilder<BusinessExtract,A.BusinessExtractBuilder<BusinessExtract,U>> to E

[srikanth-sankaran]

Reproduced on master/HEAD.

Regression arises from commit 74f1579

Looking at the heading of the comment that reads: Overhaul of how type inference handles capture bounds Phase 2: Rewrite dependency-computation I am hopeful this is covered by the recent spec clarification we received from javac folk.

@stephan-herrmann - Can you please take a look ? TIA

[srikanth-sankaran]

Here is a capture of the evolving trace capability from the work on #4838

@stephan-herrmann : can you take a look and see if this offers some insight into what causes the divergence. It is likely the logging is incomplete and you may want data at additional points.

I should call out that when I peek at the generated dot files, they contain some additional bounds - these seem to come and go inside resolution step and I am taking a snapshot of the inference context before and after resolution and this seems to miss some bounds that come and go. Not sure if/how material this is.

(Speculative) (BASIC)  attempt to instantiate method: <U> create()U
Initial Bound Set (B0):
U <: X.BusinessExtractBuilder<U>
Bound set after Invocation Applicability Inference (B2): <Ditto>
Bound set after resolution: <Ditto>
Instantiated Method Type : ()U
-----------------------------------------------
(Speculative) (BASIC)  attempt to instantiate method: <E> of(E)java.util.List<E> with arguments: DeferredType
Bound set after Invocation Applicability Inference (B2): 
E :> U
U <: X.BusinessExtractBuilder<U>
Bound set after resolution: <Ditto>
Instantiated Method Type : (java.lang.Object)java.util.List<java.lang.Object>
-----------------------------------------------
(Speculative) (BASIC)  attempt to instantiate method: <E> of(E)java.util.List<E> with arguments: DeferredType
Bound set after Invocation Applicability Inference (B2): 
E :> U
U <: X.BusinessExtractBuilder<U>
Bound set after resolution: <Ditto>
Instantiated Method Type : (java.lang.Object)java.util.List<java.lang.Object>
-----------------------------------------------
(Speculative) (BASIC)  attempt to instantiate method: <U> create()U
Initial Bound Set (B0):
U <: X.BusinessExtractBuilder<U>
Bound set after Invocation Applicability Inference (B2): <Ditto>
Bound set after resolution: <Ditto>
Instantiated Method Type : ()U
-----------------------------------------------
(Final) (BASIC)  attempt to instantiate method: <U> create()U
Initial Bound Set (B0):
U <: X.BusinessExtractBuilder<U>
Bound set after Invocation Applicability Inference (B2): <Ditto>
Bound set after incorporation: <Ditto>
Propagating inference context outwards:
E :> U
U <: X.BusinessExtractBuilder<U>
Method type at propagation point: ()U
-----------------------------------------------
(Final) (BASIC)  attempt to instantiate method: <E> of(E)java.util.List<E> with arguments: DeferredType
Bound set after Invocation Applicability Inference (B2): 
E :> U
U <: X.BusinessExtractBuilder<U>
Bound set after incorporation: 
E :> U
U <: E
U <: X.BusinessExtractBuilder<U>
Bound set after resolution: 
E :> U
U <: X.BusinessExtractBuilder<U>
Instantiated Method Type : (java.lang.Object)java.util.List<java.lang.Object>
-----------------------------------------------

[RoiSoleil]

Any news ?

[stephan-herrmann]

Here is a capture of the evolving trace capability from the work on #4838

@stephan-herrmann : can you take a look and see if this offers some insight into what causes the divergence. It is likely the logging is incomplete and you may want data at additional points.

This seems to go in a good direction, but interestingly, it doesn't even touch the point, where ecj fails:

We have an outer inference of of() and an inner inference of create(). Ecj succeeds to infer applicability of the inner, then fully infers the outer, but fails when completing the job by invocation type inference for the inner. This last step requires a target type, which can only be provided once the outer inference is done.

The above output from javac shows "Final" inference of the inner, before the outer is done. This looks odd. Here I'd need to see the target type for Invocation Type Inference. For that target type I'd further need to see if we have an inference variable or a proper type or a fresh type variable. In ecj the inference variable would have a name like U#0, whereas a fresh type variable looks like Z#0-U#0 (the letter Z being a constant).

@srikanth-sankaran can you help me understand javac's stages of inference?

JLS requires these steps:

• 18.5.1 Invocation Applicability Inference
  • test for applicability by strict invocation
  • test for applicability by loose invocation
  • test for applicability by variable arity invocation
• 18.5.2 Invocation Type Inference (which needs a target type)

Additionally, there is the concept of "potentially compatible" in 15.12.2.1.

In the above output I see terminology that doesn't easily align with JLS:

• Speculative/Final
• BASIC
• Bound set after Invocation Applicability Inference

How do these relate to the steps from JLS? In particular, where do we see Invocation Type Inference at work?

[stephan-herrmann]

Actually, the distinction of "kinds of types" (see also #4838 (comment)) is essential for the case at hand: ecj fails after generating this type bound:

• U#0 = E (see that the RHS is a regular type variable, not an inference variable)

During incorporation it creates this constraint:

• ⟨E <: A.BusinessExtractBuilder<U#0>⟩ -- which reduces to false, because <E extends Object> is incompatible with the RHS.

[stephan-herrmann]

While I'm at it, here are some more details of how ecj fails:

Resolution for List.of() works on this bound set:

	U#0 <: A.BusinessExtractBuilder<U#0>
	U#0 <: E#1

We try to resolve both ivars at once, which fails during incorporation, when we have this bound set:

	TypeBound  U#0 = java.lang.Object
	Dependency U#0 <: A.BusinessExtractBuilder<U#0>
	Dependency U#0 <: E#1
	TypeBound  U#0 <: A.BusinessExtractBuilder<java.lang.Object>
	TypeBound  E#1 = java.lang.Object

then we derive the following failing constraint:

• ⟨java.lang.Object <: A.BusinessExtractBuilder<U#0>⟩

After this failure we proceed with the "second attempt":

• create fresh type variables <Z#1-U#0> and <Z#0-E#1>
• for the former we try to set these upper bounds:
  • <Z#0-E#1>
  • BusinessExtractBuilder<Z#1-U#0>
• here isConsistentIntersection() answers false, which lets inference fail immediately
  • inconsistency is detected because we can't find a most specific among the two given types
  • most specific is required because both types answer true to isClass()
    • the logic here is: it's a class unless we know it to be an interface, annotation or enum

If we tweak the code section, so we pass isConsistentIntersection(), then we end up with an incorporation error, with this bound set:

	TypeBound  U#0 = Z#0-E#1 & A.BusinessExtractBuilder<Z#0-E#1 & A.BusinessExtractBuilder<U>>
	Dependency U#0 <: A.BusinessExtractBuilder<U#0>
	Dependency U#0 <: E#1
	TypeBound  U#0 <: A.BusinessExtractBuilder<Z#0-E#1 & A.BusinessExtractBuilder<Z#0-E#1 & A.BusinessExtractBuilder<U>>>
	TypeBound  U#0 <: Z#0-E#1
	TypeBound  E#1 :> Z#0-E#1&A.BusinessExtractBuilder<Z#0-E#1&A.BusinessExtractBuilder<U>>
	TypeBound  E#1 = Z#0-E#1

from which we derive this failing constraint:

• ⟨<Z#1-U#0 extends Z#0-E#1> <: A.BusinessExtractBuilder<Z#0-E#1 & A.BusinessExtractBuilder<Z#0-E#1 & A.BusinessExtractBuilder<U>>>⟩

wow, this is getting complex :)

[stephan-herrmann]

Knowing that we should instantiate E#1 to j.l.Object, we may guess that we should resolve E#1 first, and only then proceed with U#0. This might be possible by further tweaks in #5004.

[srikanth-sankaran]

• Speculative/Final
• BASIC

I can offer ready explanations for these, while other questions will need investigation - I'll look into it.

Speculative vs Final is about target type being known for sure (Final after overload resolution picked a method) vs - candidate methods being considered one by one and the positional parameter type being the speculative target type.

BASIC/BOX/VARARITY is about the three distinct phases of overload resolution to consider in that order,

[RoiSoleil]

The proposed solution in stephan-herrmann@888c7cd works on my full codebase ;) Thx