ecj-javac record type inference difference #3796

mpalat · 2025-03-14T05:53:02Z

WIP - DRAFT

			interface I<T> {}
			record R<T>(T t) {}

			public class X  {

			    static <T> boolean foo(R<T> y) {
			       if (y.t() instanceof R(var v)) {
			            var t = new R<>(v);
			            R<Object> r = t; //error  shown [Type mismatch: cannot convert from R<capture#2-of ?> to R<Object>]
			            return true;
			        }
			        return false;
			    }
			    public static void main(String argv[]) {
			        System.out.println(foo(new R<R<Object>>(new R<>(new X()))));
			    }
			}

What it does

Test case that shows difference between javac and ecj behaviour. javac compiles and prints true while running while ecj gives the following error:
"Type mismatch: cannot convert from R<capture#2-of ?> to R"

How to test

The code above is a reproducible testcase. Currently t 8000 he fix is in the works. The patch contains the test case only as of now.

Author checklist

I have thoroughly tested my changes
The change is following the coding conventions
I have signed the Eclipse Contributor Agreement (ECA)

stephan-herrmann · 2025-03-14T22:21:08Z

In the test case I see three different things called "T".
Has it been written somewhere that all type parameters are called "T"?
Do yourself a favor and invest those 10 seconds to 'invent' different names.
How else do you want to keep track which is which?

stephan-herrmann · 2025-03-14T23:19:26Z

Preliminary comments:

We perform record type inference with an expression of type <T>, an unbounded type variable.

From the items of 18.5.5 I see only these as applicable:

2: so an initial bound set is created (which however is empty due to lack of declared bounds)
5: resolution without sufficient information creates a CaptureBinding18 Z#0-T#0
6: I see upwards projection converting R<Z#0-T#0> into R<?>.

Note in particular that items 3 and 4 are not really applicable. There's one oddity in item 3: it's all about the case of T being a parameterized type, from which betas are derived and how further constraints are created for them. Hidden in that list of inapplicable steps there are two bullets for the "outer else", i.e., when T is not a parameterized type. But even that bullet is moot for our case, as it only derives further constraints from a type variable's bound, but our type variable has no bounds.

Let's assume for a moment that R<?> is the correct result from 6. Since 9e5215a we immediately capture that type to the R<capture#2-of ?> we see in the error message. We might discuss with @srikanth-sankaran the exact capturing story. See, e.g., that a few lines down in RecordPattern.resolveType() we say this.resolvedType.capture(..) on the already captured type 😛

But none of this would transform the wildcard (captured or not) into type j.l.Object as required for accepting the program.

Next idea: perhaps somewhere down the line we treat <T> as having no bound, where perhaps we should regard it as <T extends Object>, but even adding explicit extends Object to all type parameters, doesn't help.

Ergo: for the moment I have no idea, what could lead us to inferring R<Object>.

mpalat added this to the 4.36 milestone Mar 14, 2025

mpalat marked this pull request as draft March 14, 2025 05:53

mpalat requested a review from stephan-herrmann March 14, 2025 05:53

mpalat self-assigned this Mar 14, 2025

ecj-javac record type inference difference

35cbdcd

mpalat force-pushed the record-type-1 branch from a864ef9 to 35cbdcd Compare April 16, 2025 05:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ecj-javac record type inference difference #3796

ecj-javac record type inference difference #3796

ecj-javac record type inference difference #3796

Are you sure you want to change the base?

ecj-javac record type inference difference #3796

Conversation

What it does

How to test

Author checklist