Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method call with wildcard generic parameter fails to compile #3367

Open
alexcormier opened this issue Nov 28, 2024 · 5 comments
Open

Method call with wildcard generic parameter fails to compile #3367

alexcormier opened this issue Nov 28, 2024 · 5 comments
Assignees
Labels
javac ecj not compatible with javac

Comments

@alexcormier
Copy link

Given a couple generic types:

class A<T> {}
class B<T> {}

And some generic methods with wildcards:

public interface Test {
   <T> B<T> b(T t);
   <T> B<A<? super T>> bOfA(B<? super T> t);
   <T> void errors(T t, B<? super T> m);

   default void test(A<String> a) {
      errors(a, bOfA(b(a)));
   }
}

This compiles with javac, but ECJ fails to compile with:

The method errors(T, B<? super T>) in the type Test is not applicable for the arguments (A<capture#1-of ?>, B<A<? super A<capture#2-of ?>>>)

This used to work fine. When we encountered #2817, we stuck to an older version until that was fixed, and then when updating after the fix we encountered this new issue. So it seems like the two issues might be related, the setup is similar too.

@jukzi jukzi added the javac ecj not compatible with javac label Dec 2, 2024
@stephan-herrmann
Copy link
Contributor

This compiles with javac, but ECJ fails to compile with:

The method errors(T, B<? super T>) in the type Test is not applicable for the arguments (A<capture#1-of ?>, B<A<? super A<capture#2-of ?>>>)

I was very curious where the first capture would come from, but indeed I see this error:

The method errors(T, B<? super T>) in the type Test is not applicable for the arguments (A<String>, B<A<? super A<String>>>)\n

@stephan-herrmann
Copy link
Contributor

Inference fails when trying to instantiate inference variable T#1 having these upper bounds:

  • java.lang.String
  • A<java.lang.String>

This clearly is unsolvable.

Let's see if there is anything suspicious on the path towards creating these two bounds.

@alexcormier
Copy link
Author

I was very curious where the first capture would come from

Oops, I pasted the wrong error message; sorry!
I used test(A<?> a) for a bit while reducing the example – that's where the captures came from – but then I got rid of that wildcard and forgot to update the error message.

@stephan-herrmann
Copy link
Contributor

stephan-herrmann commented Dec 5, 2024

First let's give distinguishable names:

			class A<S> {}
			class B<T> {}
			public interface Test {
			   <U> B<U> b(U t);
			   <V> B<A<? super V>> bOfA(B<? super V> t);
			   <W> void errors(W t, B<? super W> m);

			   default void test(A<String> a) {
			      errors(a, bOfA(b(a)));
			   }
			}
  • Now innermost inference (for b(a)) gives:
    • TypeBound U#0 :> A<String>
  • Inferring applicability of bOfA(..) produces
    • TypeBound U#0 :> A<String>
    • Dependency V#1 <: U#0

Outer inference for error(..) starts with

Initial Constraints:
	⟨a → W#2⟩
	⟨bOfA(b(a)) → B<? super W#2>⟩

Reduction:

  • ⟨a → W#2⟩
    • ⟨A<String> → W#2⟩
      • ⟨A<String> <: W#2⟩
        • TypeBound W#2 :> A<String>
  • ⟨bOfA(b(a)) → B<? super W#2>⟩
    • integrates bounds from inner inference to result in
      • TypeBound W#2 :> A<String>
      • TypeBound U#0 :> A<String>
      • Dependency V#1 <: U#0
    • ⟨B<A<? super V#1>> → B<? super W#2>⟩
      • ⟨B<A<? super V#1>> <: B<? super W#2>⟩
        • ⟨A<? super V#1> <= ? super W#2⟩
          • ⟨W#2 <: A<? super V#1>⟩
            • Dependency W#2 <: A<? super V#1>

At this point we have

	TypeBound  W#2 :> A<String>
	Dependency W#2 <: A<? super V#1>
	TypeBound  U#0 :> A<String>
	Dependency V#1 <: U#0

Incorporation:

  • W#2 :> A<String> & W#2 <: A<? super V#1>
    • ⟨A<String> <: A<? super V#1>⟩
      • ⟨String <= ? super V#1⟩
        • ⟨V#1 <: String⟩
          • V#1 <: String
  • W#2 <: A<? super V#1> & W#2 :> A<String>
    • ⟨A<String> <: A<? super V#1>⟩
      • duplicate of previous

Incorporation result:

	TypeBound  W#2 :> A<String>
	Dependency W#2 <: A<? super V#1>
	TypeBound  U#0 :> A<String>
	Dependency V#1 <: U#0
	TypeBound  V#1 <: String

Resolve:

  • TypeBound U#0 = A<String> -- from lub
    • incorporate
      • ⟨V#1 <: A<String>⟩
        • TypeBound V#1 <: A<String>
      • ⟨V#1 <: A<String>⟩
  • V#1 has upper bounds:
    • String
    • A<String>
    • glb is an impossible intersection => FAIL

So let me go over these steps if there is anything suspicous. So far nothing found.

@stephan-herrmann
Copy link
Contributor

This variant demonstrates that a solution exists (with U = Object):

class A<S> {}
class B<T> {}
public abstract class Test {
	abstract <U> B<U> b(U t);
	abstract <V> B<A<? super V>> bOfA(B<? super V> t);
	abstract <W> void errors(W t, B<? super W> m);

	void test(A<String> a) {
		errors(a, bOfA(this.<Object>b(a)));
	}
}

Does inference have the rules to find this solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
javac ecj not compatible with javac
Projects
None yet
Development

No branches or pull requests

3 participants