JDK-8244712 : [lworld] Javac should switch to reference projection before walking type hierarchy.
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: repo-valhalla
  • Priority: P4
  • Status: Resolved
  • Resolution: Withdrawn
  • OS: generic
  • CPU: generic
  • Submitted: 2020-05-11
  • Updated: 2024-02-23
  • Resolved: 2024-02-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
repo-valhallaResolved
Related Reports
Relates :  
Description
The following is documented in https://github.com/openjdk/valhalla/pull/32 as a known issue that has been deliberately deferred to a later iteration:

Class hierarchy walking in a world where inline types are islands calls for a type switch. I have done this only in places uncovered by existing tests. We need to go through various utility methods (similar to what is done in Symbol.java and Resolve.java) to make sure these changes are consistently applied.

This ticket is to follow up on this. JDK-8244711 covers this for interface implementation checks.
Comments
Copying over my observation from elsewhere: I think the work we have now rather literally implements Brian's diktat in SoV that a primitive class type is an island and at the language level it is is not a subtype of jlO What is possible is for us under the hood not literally implement such a model but just in phase 1 of overload selection and a few other select places implement that model and everywhere else simply gloss over that Effectively implementing Brian's model rather than literally implementing it
09-04-2021

Carrying over Maurizio's observations from elsewhere (about Types.asSuper plausibly internally always coercing its first argument to a reference projection and upon being pointed out that isSubtype internally calls asSuper) isSubtype calls asSuper, yes but my idea was that isSubtype shuld quickly exit if the LHS type is a val projection and only get to asSuper if that's ok to do as for Infer, the idea is that, during inference, we're always in boxing mode so .ref should always be the assumption there e.g. like passing int where an inference var Z is expected you don't work with int directly, you work with box(int) so my intuition says that working with ref projections should be fine there too (that said, I'm ok with deferring for further evaluation) but, I guess, my main gripe is with the fact that: asSuper(foo.val.type, Object) == null I'm not 100% sure this is the right way to go about things IMHO, asSuper is a function that should "lift" the LHS to the same "height" in the supertype chain as the RHS and then re-sprinkle type stuff on top e.g. asSuper(List<String>, Collection) == Collection<String> you can imagine this as "walk the supertype chain of List<String> and give me a supertype whose base class is Collection" (edited) or you can imagine this as "lift List<String> into Collection (if they are related by subclassing) and rewrire the type parameters in there" my feeling is that the first interpretation is too strict for the new use cases e.g. there has to be a way to ask the compiler: given a type T (whether ref/val we don't care) is that T related in any way to another symbol S ? membership is a good area to explore: if primitive class P implements I I guess I can see I methods as "members" of P.val, right? (edited) to me, this seems to suggests that under the hood P.val and P.ref are more connected than it seems it's just subtyping (and few other places) which will insert extra checks for P.val vs. P.ref but I guess I'd like for the code to land in a place where, in case where P.val vs. P.ref difference matters, these places stand out and leave all the rest of the code (which I bet, in large part is oblivious to the ref/val distinction) unchanged
09-04-2021