8000 Method call compiles with javac but not ecj with upper bound of type variable by stephan-herrmann · Pull Request #4116 · eclipse-jdt/eclipse.jdt.core · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Method call compiles with javac but not ecj with upper bound of type variable #4116

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Method call compiles with javac but not ecj with upper bound of type variable #4116

wants to merge 2 commits into from
+93 −32

Conversation

stephan-herrmann
Copy link
Contributor

Fix CaptureBinding.initializeBounds() by more closely adhering to JLS

Fix a bug in glb concerning T#RAW vs T or T<?>

  • this fix includes making RawTypeBinding.isSubtypeOf() stricter

Fixes #2523

@stephan-herrmann
Copy link
Contributor Author

@coehlrich do you want to join me discussing which solution for #2523 is more suitable?

@stephan-herrmann
Copy link
Contributor Author

The basic idea here is to collect all relevant bounds from the wildcard and the corresponding type variable, perform substitution and then compute glb of them all.

If glb is defined, simply pick the class, if any, make it the superclass, and put the rest into superInterfaces.

The else-branch (the case of fullGlb==null) is less rigorously motivated. In many cases this branch could actually be avoided if getAllAllUpperBounds() would filter out any reference to java.lang.Object. There seems to be more to it, though. Could null glb indicate an actual bound error? Would this (always) correlate to a bound error of the parameterized type being captured?

Interestingly, this experiment triggered one regression which could be traced back to a bogus result of glb: we were computing glb(T#RAW, T<?>) as T#RAW. But T#RAW is not a subtype of T<?>, it is only convertible to it. This could be fixed by small changes in greaterLowerBound() itself plus an addition in RawTypeBinding.isSuperTypeOf(). These changes might be valuable in their own right.

@stephan-herrmann stephan-herrmann mentioned this pull request Jun 19, 2025
Open
coehlrich and others added 2 commits July 8, 2025 16:41
@coehlrich @stephan-herrmann
Method call compiles with javac but not ecj with upper bound of type
b1b317a 
variable

Fix CaptureBinding.initializeBounds() by more closely adhering to JLS

Fix a bug in glb concerning T#RAW vs T<X> or T<?>
+ this fix includes making RawTypeBinding.isSubtypeOf() stricter

Fixes eclipse-jdt#2523

Also-by: Stephan Herrmann <stephan.herrmann@berlin.de>
@stephan-herrmann
Method call compiles with javac but not ecj with upper bound of type
93a07ae 
variable

+ reduce the code and document correspondence to JLS

Fixes eclipse-jdt#2523
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Method call compiles with javac but not ecj with upper bound of type variable
2 participants
@stephan-herrmann @coehlrich
0