compiler-dev Digest, Vol 117, Issue 3
Asim Aslam
asim2025 at yahoo.com
Tue Jan 10 01:07:15 UTC 2017
> On Jan 9, 2017, at 7:02 PM, compiler-dev-request at openjdk.java.net wrote:
>
> Send compiler-dev mailing list submissions to
> compiler-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/compiler-dev
> or, via email, send a message with subject or body 'help' to
> compiler-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> compiler-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of compiler-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: RFR 8172214: typo in 'intersection types in cast are not
> supported' message (Maurizio Cimadamore)
> 2. RFR: backport for fix
> https://bugs.openjdk.java.net/browse/JDK-8172291 (Maurizio Cimadamore)
> 3. Re: RFR: backport for fix
> https://bugs.openjdk.java.net/browse/JDK-8172291 (Vicente Romero)
> 4. Re: [PATCH] 8148100: Convert lambda most specific positive
> tests to check runtime behavior (Vicente Romero)
> 5. Re: [PATCH] 8148100: Convert lambda most specific positive
> tests to check runtime behavior (B. Blaser)
> 6. JDK 9 RFR of JDK-8172458: Make javax.lang.model javadoc HTML
> 5 compliant (joe darcy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 4 Jan 2017 15:35:39 +0000
> From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> To: Liam Miller-Cushon <cushon at google.com>,
> "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
> Subject: Re: RFR 8172214: typo in 'intersection types in cast are not
> supported' message
> Message-ID: <db50dc86-1417-f871-1b4d-77fda79edaf8 at oracle.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Pushed - thanks
>
> Maurizio
>
>
>> On 03/01/17 22:07, Maurizio Cimadamore wrote:
>>
>> Looks good thanks!
>>
>> Maurizio
>>
>>
>>> On 03/01/17 21:58, Liam Miller-Cushon wrote:
>>> This fixes a typo in
>>> compiler.err.intersection.types.in.cast.not.supported.in.source,
>>> which incorrectly refers to default methods instead of intersection
>>> types in cast.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172214
>>> Webrev: http://cr.openjdk.java.net/~cushon/8172214/webrev.00/
>>> <http://cr.openjdk.java.net/%7Ecushon/8172214/webrev.00/>
>>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170104/322271c7/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 5 Jan 2017 16:35:50 +0000
> From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> To: "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
> Subject: RFR: backport for fix
> https://bugs.openjdk.java.net/browse/JDK-8172291
> Message-ID: <66bedc11-561f-3912-46ed-517ee42fe466 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
> please review the backport:
>
> https://bugs.openjdk.java.net/browse/JDK-8172291
>
> The original issue is here (fixed in 9):
>
> https://bugs.openjdk.java.net/browse/JDK-8168774
>
> The JDK 9 patch does not apply cleanly because:
>
> * Types.isSignaturePolymorphic has changed in 9 because of VarHandles
> * the test (BadPolySig) contains jtreg module directives which are not
> valid in 8
>
> Webrev here:
>
> http://cr.openjdk.java.net/~mcimadamore/8172291/
>
> Cheers
> Maurizio
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 5 Jan 2017 12:47:29 -0500
> From: Vicente Romero <vicente.romero at oracle.com>
> To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>,
> "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
> Subject: Re: RFR: backport for fix
> https://bugs.openjdk.java.net/browse/JDK-8172291
> Message-ID: <4c9a8940-3860-b033-4a64-271f022dab12 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> accepted
>
> Vicente
>
>
>> On 01/05/2017 11:35 AM, Maurizio Cimadamore wrote:
>> Hi,
>> please review the backport:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8172291
>>
>> The original issue is here (fixed in 9):
>>
>> https://bugs.openjdk.java.net/browse/JDK-8168774
>>
>> The JDK 9 patch does not apply cleanly because:
>>
>> * Types.isSignaturePolymorphic has changed in 9 because of VarHandles
>> * the test (BadPolySig) contains jtreg module directives which are not
>> valid in 8
>>
>> Webrev here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8172291/
>>
>> Cheers
>> Maurizio
>>
>>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 5 Jan 2017 14:32:35 -0500
> From: Vicente Romero <vicente.romero at oracle.com>
> To: "B. Blaser" <bsrbnd at gmail.com>, Jonathan Gibbons
> <jonathan.gibbons at oracle.com>
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: [PATCH] 8148100: Convert lambda most specific positive
> tests to check runtime behavior
> Message-ID: <bc9c79e8-5caa-16a7-9b72-0203e9260496 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> pushed,
>
> Thanks,
> Vicente
>
>> On 12/14/2016 09:50 AM, Vicente Romero wrote:
>> Hi Bernard,
>>
>> Very sorry for the delay with your patch, I will take care of it,
>>
>> Vicente
>>
>>> On 12/12/2016 04:40 AM, B. Blaser wrote:
>>> Hi,
>>> Does this patch need to be improved?
>>>
>>> Thanks,
>>> Bernard
>>>
>>> 2016-09-21 16:24 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>> Please find in attachment an all-in-one patch for the 9 tests, as
>>>> discussed previously.
>>>>
>>>> Bernard
>>>>
>>>>
>>>> 2016-09-19 16:01 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>>> Thanks for your advices.
>>>>>
>>>>> I re-wrote, below, the patch in a more compliant way (I hope).
>>>>> I'll perhaps (probably) also go through the 8 others soon, if I
>>>>> have time...
>>>>>
>>>>> Bernard
>>>>>
>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java
>>>>> b/test/tools/javac/lambda/MostSpecific10.java
>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java
>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java
>>>>> @@ -25,9 +25,12 @@
>>>>> * @test
>>>>> * @bug 8034223
>>>>> * @summary Structural most-specific logic for lambdas, method refs,
>>>>> parens, and conditionals
>>>>> - * @compile MostSpecific10.java
>>>>> */
>>>>> -class MostSpecific10 {
>>>>> +public class MostSpecific10 {
>>>>> +
>>>>> + public static void main(String[] args) {
>>>>> + new MostSpecific10().test(true);
>>>>> + }
>>>>>
>>>>> interface GetInt {
>>>>> int get();
>>>>> @@ -38,7 +41,9 @@
>>>>> }
>>>>>
>>>>> void m(GetInt getter) {}
>>>>> - void m(GetInteger getter) {}
>>>>> + void m(GetInteger getter) {
>>>>> + throw new RuntimeException("Less-specific method invocation:
>>>>> " + getter.getClass());
>>>>> + }
>>>>>
>>>>> void test(boolean cond) {
>>>>> m(() -> 23);
>>>>>
>>>>>
>>>>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons
>>>>> <jonathan.gibbons at oracle.com>:
>>>>>> Bernard,
>>>>>>
>>>>>> Thanks for posting this patch.
>>>>>>
>>>>>> It's not wrong to say it explicitly, but the addition of the "@run
>>>>>> main"
>>>>>> line is unnecessary, since that is the default behavior once you
>>>>>> remove the
>>>>>> @compile.
>>>>>>
>>>>>> The replacement for void m(GetInteger getter) should be formatted
>>>>>> in a more
>>>>>> standard manner.
>>>>>>
>>>>>> It's more common to put the main method at the head of a test,
>>>>>> instead of at
>>>>>> the end.
>>>>>>
>>>>>> We can't check in "partial patches", so either you have to look at
>>>>>> the 8
>>>>>> other tests and fix them all together, or we have to accept this
>>>>>> one change
>>>>>> as a "complete" fix for 8148100, and open a new, different issue
>>>>>> for the 8
>>>>>> other tests. (The OpenJDK rules only permit one changeset per
>>>>>> issue per
>>>>>> repo,)
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 9/17/16 10:16 AM, bsrbnd wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just wrote a partial patch for issue 8148100.
>>>>>>> This is an updated version of
>>>>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the
>>>>>>> most-specific method is run with respect to JLS 15.12.2 (and also as
>>>>>>> explained in the issue description).
>>>>>>> I've not checked the 8 other tests yet...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bernard
>>>>>>>
>>>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java
>>>>>>> b/test/tools/javac/lambda/MostSpecific10.java
>>>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java
>>>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java
>>>>>>> @@ -26,8 +26,9 @@
>>>>>>> * @bug 8034223
>>>>>>> * @summary Structural most-specific logic for lambdas, method
>>>>>>> refs,
>>>>>>> parens, and conditionals
>>>>>>> * @compile MostSpecific10.java
>>>>>>> + * @run main MostSpecific10
>>>>>>> */
>>>>>>> -class MostSpecific10 {
>>>>>>> +public class MostSpecific10 {
>>>>>>>
>>>>>>> interface GetInt {
>>>>>>> int get();
>>>>>>> @@ -38,7 +39,7 @@
>>>>>>> }
>>>>>>>
>>>>>>> void m(GetInt getter) {}
>>>>>>> - void m(GetInteger getter) {}
>>>>>>> + void m(GetInteger getter) {throw new
>>>>>>> RuntimeException("Less-specific method invocation: " +
>>>>>>> getter.getClass());}
>>>>>>>
>>>>>>> void test(boolean cond) {
>>>>>>> m(() -> 23);
>>>>>>> @@ -50,5 +51,9 @@
>>>>>>> m(cond ? (() -> 23) : ("abc"::length) );
>>>>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() ->
>>>>>>> 23) ));
>>>>>>> }
>>>>>>> +
>>>>>>> + public static void main(String[] args) {
>>>>>>> + new MostSpecific10().test(true);
>>>>>>> + }
>>>>>>>
>>>>>>> }
>>>>>>
>>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 8 Jan 2017 13:43:22 +0100
> From: "B. Blaser" <bsrbnd at gmail.com>
> To: Vicente Romero <vicente.romero at oracle.com>
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: [PATCH] 8148100: Convert lambda most specific positive
> tests to check runtime behavior
> Message-ID:
> <CAEgw74B77pKb1psQ86Gi5qh=CJss-eDoHuGd-x2kpOnN=N2OYA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Fine, thanks!
> Bernard
>
> 2017-01-05 20:32 GMT+01:00 Vicente Romero <vicente.romero at oracle.com>:
>> pushed,
>>
>> Thanks,
>> Vicente
>>
>>
>>> On 12/14/2016 09:50 AM, Vicente Romero wrote:
>>>
>>> Hi Bernard,
>>>
>>> Very sorry for the delay with your patch, I will take care of it,
>>>
>>> Vicente
>>>
>>>> On 12/12/2016 04:40 AM, B. Blaser wrote:
>>>>
>>>> Hi,
>>>> Does this patch need to be improved?
>>>>
>>>> Thanks,
>>>> Bernard
>>>>
>>>> 2016-09-21 16:24 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>>>
>>>>> Please find in attachment an all-in-one patch for the 9 tests, as
>>>>> discussed previously.
>>>>>
>>>>> Bernard
>>>>>
>>>>>
>>>>> 2016-09-19 16:01 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>>>>
>>>>>> Thanks for your advices.
>>>>>>
>>>>>> I re-wrote, below, the patch in a more compliant way (I hope).
>>>>>> I'll perhaps (probably) also go through the 8 others soon, if I have
>>>>>> time...
>>>>>>
>>>>>> Bernard
>>>>>>
>>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java
>>>>>> b/test/tools/javac/lambda/MostSpecific10.java
>>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java
>>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java
>>>>>> @@ -25,9 +25,12 @@
>>>>>> * @test
>>>>>> * @bug 8034223
>>>>>> * @summary Structural most-specific logic for lambdas, method refs,
>>>>>> parens, and conditionals
>>>>>> - * @compile MostSpecific10.java
>>>>>> */
>>>>>> -class MostSpecific10 {
>>>>>> +public class MostSpecific10 {
>>>>>> +
>>>>>> + public static void main(String[] args) {
>>>>>> + new MostSpecific10().test(true);
>>>>>> + }
>>>>>>
>>>>>> interface GetInt {
>>>>>> int get();
>>>>>> @@ -38,7 +41,9 @@
>>>>>> }
>>>>>>
>>>>>> void m(GetInt getter) {}
>>>>>> - void m(GetInteger getter) {}
>>>>>> + void m(GetInteger getter) {
>>>>>> + throw new RuntimeException("Less-specific method invocation:
>>>>>> " + getter.getClass());
>>>>>> + }
>>>>>>
>>>>>> void test(boolean cond) {
>>>>>> m(() -> 23);
>>>>>>
>>>>>>
>>>>>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons
>>>>>> <jonathan.gibbons at oracle.com>:
>>>>>>>
>>>>>>> Bernard,
>>>>>>>
>>>>>>> Thanks for posting this patch.
>>>>>>>
>>>>>>> It's not wrong to say it explicitly, but the addition of the "@run
>>>>>>> main"
>>>>>>> line is unnecessary, since that is the default behavior once you
>>>>>>> remove the
>>>>>>> @compile.
>>>>>>>
>>>>>>> The replacement for void m(GetInteger getter) should be formatted in a
>>>>>>> more
>>>>>>> standard manner.
>>>>>>>
>>>>>>> It's more common to put the main method at the head of a test, instead
>>>>>>> of at
>>>>>>> the end.
>>>>>>>
>>>>>>> We can't check in "partial patches", so either you have to look at the
>>>>>>> 8
>>>>>>> other tests and fix them all together, or we have to accept this one
>>>>>>> change
>>>>>>> as a "complete" fix for 8148100, and open a new, different issue for
>>>>>>> the 8
>>>>>>> other tests. (The OpenJDK rules only permit one changeset per issue
>>>>>>> per
>>>>>>> repo,)
>>>>>>>
>>>>>>> -- Jon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 9/17/16 10:16 AM, bsrbnd wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I just wrote a partial patch for issue 8148100.
>>>>>>>> This is an updated version of
>>>>>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the
>>>>>>>> most-specific method is run with respect to JLS 15.12.2 (and also as
>>>>>>>> explained in the issue description).
>>>>>>>> I've not checked the 8 other tests yet...
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bernard
>>>>>>>>
>>>>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java
>>>>>>>> b/test/tools/javac/lambda/MostSpecific10.java
>>>>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java
>>>>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java
>>>>>>>> @@ -26,8 +26,9 @@
>>>>>>>> * @bug 8034223
>>>>>>>> * @summary Structural most-specific logic for lambdas, method
>>>>>>>> refs,
>>>>>>>> parens, and conditionals
>>>>>>>> * @compile MostSpecific10.java
>>>>>>>> + * @run main MostSpecific10
>>>>>>>> */
>>>>>>>> -class MostSpecific10 {
>>>>>>>> +public class MostSpecific10 {
>>>>>>>>
>>>>>>>> interface GetInt {
>>>>>>>> int get();
>>>>>>>> @@ -38,7 +39,7 @@
>>>>>>>> }
>>>>>>>>
>>>>>>>> void m(GetInt getter) {}
>>>>>>>> - void m(GetInteger getter) {}
>>>>>>>> + void m(GetInteger getter) {throw new
>>>>>>>> RuntimeException("Less-specific method invocation: " +
>>>>>>>> getter.getClass());}
>>>>>>>>
>>>>>>>> void test(boolean cond) {
>>>>>>>> m(() -> 23);
>>>>>>>> @@ -50,5 +51,9 @@
>>>>>>>> m(cond ? (() -> 23) : ("abc"::length) );
>>>>>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> 23)
>>>>>>>> ));
>>>>>>>> }
>>>>>>>> +
>>>>>>>> + public static void main(String[] args) {
>>>>>>>> + new MostSpecific10().test(true);
>>>>>>>> + }
>>>>>>>>
>>>>>>>> }
>>>>>>>
>>>>>>>
>>>
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 9 Jan 2017 16:02:13 -0800
> From: joe darcy <joe.darcy at oracle.com>
> To: "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
> Subject: JDK 9 RFR of JDK-8172458: Make javax.lang.model javadoc HTML
> 5 compliant
> Message-ID: <8789276c-8cad-8d31-6435-02555cd470ba at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> The javadoc in javax.lang.model.* and javax.annotation.processing use
> some constructs that are not HTML 5 compliant. These constructs should
> be updated to be compliant with HTML 5, mostly replacing <tt></tt> tags
> with <code></code>. Please review the proposed changes below:
>
> JDK-8172458: Make javax.lang.model javadoc HTML 5 compliant:
> https://bugs.openjdk.java.net/browse/JDK-8172458
> webrev: http://cr.openjdk.java.net/~darcy/8172458.0/
>
> Thanks,
>
> -Joe
>
>
>
>
> End of compiler-dev Digest, Vol 117, Issue 3
> ********************************************
More information about the compiler-dev
mailing list