8237072: [lworld] Add support for denoting and deriving the reference projection #32
Hello Maurizio & Jim,
under the new scheme ? TIA.
I. What does this patch do?
I. What does this patch do:
II. These files can be skipped as they simply revert change and align
III. Recommended order for review:
IV. There are many known issues that have been deliberately deferred to a later iteration:
V. Problems in the interplay of inlines types with generics and inference:
constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
a short term answer (so that the JDK components tests that are impacted don't get
Here is a snippet that captures these problems:
The text was updated successfully, but these errors were encountered:
I've tried to reproduce the checkcast issue mentioned by Mauricio with this code:
But I got an NPE where it was expected:
For this one, I think something that an approach that could be discussed would be to consider the method reference
In such cases we infer the right parameterization from the context; here it would be nice if we could infer the right val/ref from the context too.
Another odd test:
Now, I don't know what's the status of inner classes and values - but this seems to suggest that member types are not copied from one scope to another (since the nested names are only resolved from the
Thanks for the review, Maurizio!
(I will look into rebasing, At the time I raised the PR request it was even with openjdk/valhalla)
I agree this suggestion if it is implementable, has promising upside potential to make the code relatively simpler.
I chose the present approach because:
These may all be solvable or worked around satisfactorily.
I agree that upside potential is promising enough to explore the presently unknown downside potential - JDK-8244227 is raised to explore that, to prototype it so we can make an informed call.
I disagree with the vocabulary. It is not backfiring! It is additional work we knowingly sign up for :) But yes, it would be good if we don't have to.
I must mention here that the LW2 implementation actually used two ClassSymbol shells that shared the members_field. I had to opt for a deeper copy to solve some problem I ran into which I am unable to recollect at my advanced geriatric stage :)
I have added this case to JDK-8244229 Thanks!
Hmm. As discussed offline, we may have to use some smoke and mirrors anyways to make them appear as one symbol when dealing with binary classes from classpath.
I have added this test case to JDK-8244229 Thanks!
This is acknowledged as a known TODO in
I have raised JDK-8244233 to cover it,
I have cleaned up these, but this is a common coding/commenting convention in Javac. See that in the same files Symbol.java & Type.java, there are about 20 other unrelated places where quotes in this `style' exist :)
Agreed it is poor choice. Fixed by expanding to ref* and val*
I have left these as is for now, as it is not clear what exactly is being suggested. If the original code is not clear enough, do outline what you have in mind. TIA
Basically, we are checking here if T <: S. This is true if T.ref <: S. Example of such a check being is Point  <: Object 
If the polarity is reversed and we are checking if Object <: Point , we would come up with
and return isSubtype(object, Point)
which will return false which is indeed the right answer for if Object <: Point 
Two clarifications: (1) there is no "behavior" here. it is only a comment I have left in for our reference as we are going to hit it the moment we are going to add support for inline type arguments. (2) And because we are going to hit it most definitely as soon as we start working on generics support that there is no ticket for that per se.
The top level exception handling really happens in com.sun.tools.javac.main.Main#compile(java.lang.String, com.sun.tools.javac.util.Context)
I have fixed the comment to just say: "tolerate Value.class" dropping the "for now" - The comment can be confusing. We should always tolerate and not report error on Value.class - thanks for catching this. (the "for now" originally meant "may be there are other such cases we will discover we may have need to support also" but we have't found anything else that must be tolerated)
No, this may not be doable - it is the intrinsic/organic cost of saying inline types are islands (i.e they have no supertypes of any kind in the lang model including jlO and any declared super types). The best that can be done is to ensure (a) the swicheroo happens for the narrowest window needed (b) the tree is restored in a finally block
Many many thanks for the review Jim!
@sadayapalam this pull request can not be integrated into
git checkout JDK-8237072 git fetch https://git.openjdk.java.net/valhalla lworld git merge FETCH_HEAD # resolve conflicts and follow the instructions given by git merge git commit -m "Merge lworld" git push