hg: valhalla/valhalla: 8221545: [lworld] Preliminary support for alternate denotation of values and boxes

[Srikanth]

Sounds good. I will work on implementing these (except for the source 
level express cast). I expect to have a fix by early next week.

Thanks
Srikanth

On 16/04/19 8:07 PM, Brian Goetz wrote:
> Let’s separate the language and VM aspects.
>
> In the language, since V <: V?, no cast is needed when assigning a V to a V?.  And no CHECKCAST is needed for the corresponding code generation.
>
> In the other direction, a CHECKCAST is definitely needed going from V? to V; the question of whether the _language_ requires an explicit cast is still up in the air.  I think we should lean on explicit casting for now, but I suspect we’ll slide back to implicit narrowing (with possible NPE).
>
> This also makes a difference for overload selection.  If I have:
>
>      m(Object o) { }
>      m(V? v) { }
>
> and a call
>
>      V v = …
>      m(v)
>
> Under the old (V.box) interpretation, we’d prefer the m(Object) overload, since it is applicable without a boxing conversion, and m(V?) would not be.  But under the new (subtyping) interpretation, we should treat them both as applicable, and V? is _more specific_ than OIbject, so we pick m(V?).
>
>
>
>> On Apr 16, 2019, at 10:30 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>
>> On a quick check, I see that on both directions, we have a compiler inserted cast.
>> As I understand, assignment of V to V? being a widening conversion, the cast should go away while
>> the other direction is still being debated.
>>
>> This should be straightforward.
>>
>> Srikanth
>>
>> On 16/04/19 7:50 PM, Brian Goetz wrote:
>>> OK, thanks.  Hopefully the new rules will be simpler, as they lean more heavily on subtyping.
>>>
>>>
>>>> On Apr 16, 2019, at 10:18 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>>>
>>>>
>>>> This change set just introduces the new notation doing nothing new about inserting casts.
>>>> I will go through the mails discussing this and follow up on a different change set.
>>>>
>>>> Thanks
>>>> Srikanth
>>>> On 16/04/19 7:32 PM, Brian Goetz wrote:
>>>>>> This was a request for LW2 - no more boxing.
>>>>> Right.  I was wondering whether we got there yet, or whether we’d just change the notation to start.
>>>>>
>>>>>> We asked for the subtype relationship for both values and for arrays.
>>>>> For arrays, the covariance rule: T <: U imples T[] <: U[] — should hold uniformly.  No need for special exceptions for value arrays.  Since
>>>>>
>>>>>      V <: Object
>>>>> and
>>>>>      V? <: Object
>>>>>
>>>>> then both V[] and V?[] are <: Object[].
>>>>>
>>>>>
>>>>>
>>>>>> For LW2 - we requested explicit checkcasts on attempts to narrow.
>>>>>>
>>>>>> Agreed that there are discussions about where this is all going after LW2 before LW10.
>>>>>>
>>>>>> thanks,
>>>>>> Karen
>>>>>>
>>>>>>> On Apr 16, 2019, at 9:24 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>>>>>
>>>>>>> Is the conversion from V to V? still considered a boxing conversion, or is it a widening conversion now?  The language we (currently think we) want is
>>>>>>>
>>>>>>>   V <: V?
>>>>>>>
>>>>>>> In the other direction, we’re still discussing whether the narrowing conversion is implicit or explicit.
>>>>>>>
>>>>>>>> On Apr 16, 2019, at 8:09 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>
>>>>>>>>    - This is the initial commit for supporting V? notation as an alternate for V.box
>>>>>>>>    - The old .box and .val notation is not withdrawn yet and can still be used, but we should really move over to the new syntax as soon as possible.
>>>>>>>>    - Existing javac tests have been replicated to use the V? syntax.
>>>>>>>>    - VBC migration related work is not done yet.
>>>>>>>>    - One issue that showed up in the parser implementation is the ambiguity at the point of seeing ?
>>>>>>>>       in  v instanceof Type? exp: exp2; I have arranged for this to be processed as a conditional rather
>>>>>>>>       than as denoting nullability.
>>>>>>>>    - On a long value type name the ? suffix does not really stand out ATM, but I guess IDE colorcoding can address this issue.
>>>>>>>>    - There is one failing test in the langtools suite (jdk/jshell/TypeNameTest.java) I will raise a follow up
>>>>>>>>      ticket to address this.
>>>>>>>>    - More testing is required and will be undertaken in the coming weeks. I request/encourage testing by the interested parties too.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Srikanth
>>>>>>>>
>>>>>>>> On 16/04/19 5:32 PM, srikanth.adayapalam at oracle.com wrote:
>>>>>>>>> Changeset: bf52db1ad4ea
>>>>>>>>> Author:    sadayapalam
>>>>>>>>> Date:      2019-04-16 17:31 +0530
>>>>>>>>> URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/bf52db1ad4ea
>>>>>>>>>
>>>>>>>>> 8221545: [lworld] Preliminary support for alternate denotation of values and boxes
>>>>>>>>>
>>>>>>>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>>>>>>>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>>>>>>>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
>>>>>>>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
>>>>>>>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
>>>>>>>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
>>>>>>>>> ! test/langtools/tools/javac/valhalla/lworld-values/BogusIncompatibility.java
>>>>>>>>> + test/langtools/tools/javac/valhalla/lworld-values/BoxValCastTest2.java
>>>>>>>>> + test/langtools/tools/javac/valhalla/lworld-values/GenericsWithQuestion.java
>>>>>>>>> + test/langtools/tools/javac/valhalla/lworld-values/GenericsWithQuestion.out
>>>>>>>>> ! test/langtools/tools/javac/valhalla/lworld-values/InnerClassAttributeValuenessTest.java
>>>>>>>>> + test/langtools/tools/javac/valhalla/lworld-values/IntercastTest2.java
>>>>>>>>> + test/langtools/tools/javac/valhalla/lworld-values/LookupOnLoxTest2.java
>>>>>>>>> ! test/langtools/tools/javac/valhalla/lworld-values/Point.java
>>>>>>>>>