ECJ fails to compile array creation with wildcard using Stream while javac and ECJ 2025-09 succeed

[coehlrich]

the latest commit for ECJ fails to compile this:

	public static void main(String[] args) {
		CompletableFuture.allOf(Stream.of(1)
			.map(value -> future(value))
			.toArray(CompletableFuture[]::new));
	}
	
	public static <T> CompletableFuture<?> future(T t) {
		return null;
	}

with the error Type mismatch: cannot convert from CompletableFuture<capture#1-of ?> to CompletableFuture<Object> on future(value) whilst ECJ 2025-09 and javac succeed.

Notably inference does not fail instead the lambda refuses to treat CompletableFuture<capture#1-of ?> as CompletableFuture<Object>.

@stephan-herrmann

[iloveeclipse]

Could it be same as the recent bug reported by Xtext: #4601 ?

[coehlrich]

#4601 was caused by 1ea01c7 while this most likely doesn't involve MethodVerifier15

[coehlrich]

This bug started with 0300f7f where before that commit during inference the CompletableFuture<?> was being capture converted but since that commit the CompletableFuture<?> becomes java.util.concurrent.CompletableFuture<(?)#4> during inference.

[srikanth-sankaran]

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

[stephan-herrmann]

Based on #4635 (comment) I have started some grand experiments to see if we can bring ecj even closer to JLS, while adding extra constitutional tweaks where needed to align with javac. Currently this is an equation with tons of unknowns, which lets me hesitate to make further code changes in the same code area.

[stephan-herrmann]

Error with 4.39M1:

Type mismatch: cannot convert from CompletableFuture<capture#1-of ?> to CompletableFuture<Object>

With #4735 :

Type mismatch: cannot convert from CompletableFuture<capture#1-of ?> to CompletableFuture<Z#0-(?)#4>

I'll have a closer look after #4735

[stephan-herrmann]

This bug started with 0300f7f where before that commit during inference the CompletableFuture<?> was being capture converted but since that commit the CompletableFuture<?> becomes java.util.concurrent.CompletableFuture<(?)#4> during inference.

The effective difference brought by 0300f7f and affecting this case is:

• MessageSend.isPolyExpression(MethodBinding) answers false instead of true for one particular method binding
• It so happens that this method binding has type PolyParameterizedGenericMethodBinding so not considering this as poly looks - weird, to say the least.
• as a result we take a different branch in JLS 18.2.1:
  • old: "if the expression is a standalone expression ..."
    • results in ⟨CompletableFuture<capture#1-of ?> → R#2⟩
  • new: "the expression is a poly expression..."
    • its during computation of B3 when we generate R#2 :> CompletableFuture<(?)#4>
    • this fresh inference variable (?)#4 is the one causing trouble downstream
• additionally, the expression future(value) is skipped in addConstraintsToC_OneExpr()

I also observed CompletableFuture[]::new being terminally resolved to a PolyTypeBinding. Not sure if this is a problem, and may not be related to the issue at hand.

[stephan-herrmann]

MessageSend.isPolyExpression(MethodBinding) answers false instead of true for one particular method binding

This was misleading: false is the correct result, answering true based on wasInferred is wrong.

After trying to fine tune when wasInferred is set, I realized that isPolyExpression() should not rely on that flag at all. The answer in our case must be false, because the return type of future() does not mention the method's type variable <T>. Returning true before analyzing the return type was the bug.