From srikanth.adayapalam at oracle.com  Tue Aug  1 12:15:44 2017
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Tue, 1 Aug 2017 17:45:44 +0530
Subject: RFR: JDK-8184989. Incorrect class file created when passing
 lambda in inner class constructor and outer is subclass
In-Reply-To: <B713E33A-9515-42CD-9029-5EF0A927F33C@gmail.com>
References: <B713E33A-9515-42CD-9029-5EF0A927F33C@gmail.com>
Message-ID: <598070F0.5070404@oracle.com>


Thanks Andrey.

I'll take a look in the coming week and let you know of any feedback.

Srikanth

On Monday 31 July 2017 08:00 PM, Andrey Petushkov wrote:
> Dear Compiler Team,
>
> We?ve occasionally found out that there is a problem in javac related 
> to lambda support, in part related to referencing the outer?s entity 
> which otherwise would be captured by using inner this, but cannot be 
> since it?s not yet fully initialized. More specifically this seem to 
> be omission in the fix for JDK-8129740 
> <https://bugs.openjdk.java.net/browse/JDK-8129740>:
> it's fix works fine if it deals with the entity from the outer 
> class(es), but fails if the entity is inherited from outer?s parent. 
> Consider the following source code:
>
> A.java
> public class A {
>     public boolean test(){
>         return true;
>     }
>     class AA{
>         public AA(Condition condition) {
>         }
>     }
> }
>
> Condition.java
> public interface Condition<T> {
>     boolean check(T t);
> }
>
> B.java
> public class B extends A {
>     private final BA myBA;
>     public B() {
>         myBA = new BA();
>     }
>     public class BA extends AA{
>         public BA() {
>             super(o -> test());
>         }
>     }
>     public static void main(String[] args) {
>         B b = new B();
>         System.out.println(b);
>     }
> }
>
>
> source compiles but execution of B fails with:
> Exception in thread "main" java.lang.VerifyError: Bad type on operand 
> stack
> Exception Details:
>   Location:
>     B$BA.lambda$new$0(LB;Ljava/lang/Object;)Z @1: getfield
>   Reason:
>     Type 'B' (current frame, stack[0]) is not assignable to 'B$BA'
>   Current Frame:
>     bci: @1
>     flags: { }
>     locals: { 'B', 'java/lang/Object' }
>     stack: { 'B' }
>   Bytecode:
>     0x0000000: 2ab4 0001 b600 04ac
>
> at B.<init>(B.java:6)
> at B.main(B.java:17)
>
> The problem is reproduced on both latest 8u and 9 (by the time of the 
> bug submission)
>
> My naive attempt to fix could be seen here 
> http://cr.openjdk.java.net/~apetushkov/8184989/webrev/ 
> <http://cr.openjdk.java.net/%7Eapetushkov/8184989/webrev/> (based on 
> latest 8u)
> Please could you consider reviewing/improving it or suggesting 
> improvement direction as appropriate
>
> Thanks,
> Andrey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170801/1cc4b900/attachment.html>

From bsrbnd at gmail.com  Wed Aug  2 13:02:59 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 2 Aug 2017 15:02:59 +0200
Subject: RFR: JDK-8184989. Incorrect class file created when passing
 lambda in inner class constructor and outer is subclass
In-Reply-To: <598070F0.5070404@oracle.com>
References: <B713E33A-9515-42CD-9029-5EF0A927F33C@gmail.com>
 <598070F0.5070404@oracle.com>
Message-ID: <CAEgw74DFonL=NL1ovQa+yZ4kM0Vo+ZkR1EdMfTxYXpc26tCG5w@mail.gmail.com>

Andrey, Srikanth, All,

At first sight, this looks good to me.

I would perhaps rewrite it as here under, to be more expressive.
I did it rapidly on a quite old jdk9 revision (sorry...), but this
should work on the latest, too.

What do you think of this rewriting?

Regards,
Bernard

diff -r 43a83431f19d
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
   Wed Mar 15 15:46:43 2017 +0100
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
   Wed Aug 02 14:11:08 2017 +0200
@@ -2103,15 +2103,23 @@
                             }
                             break;
                         case CAPTURED_OUTER_THIS:
-                            if (lambdaIdent.sym.owner.kind == TYP &&
m.containsKey(lambdaIdent.sym.owner)) {
-                                // Transform outer instance variable
references anchoring them to the captured synthetic.
-                                Symbol tSym = m.get(lambdaIdent.sym.owner);
-                                JCExpression t =
make.Ident(tSym).setType(lambdaIdent.sym.owner.type);
-
tSym.setTypeAttributes(lambdaIdent.sym.owner.getRawTypeAttributes());
-                                t = make.Select(t, lambdaIdent.name);
-                                t.setType(lambdaIdent.type);
-                                TreeInfo.setSymbol(t, lambdaIdent.sym);
-                                return t;
+                            if (lambdaIdent.sym.owner.kind == TYP) {
+                                for (Symbol out: m.keySet()) {
+                                    for (Type type = out.type;
+                                            type.hasTag(CLASS) &&
!type.isErroneous();
+
type=((ClassSymbol)type.tsym).getSuperclass()) {
+                                        if
(type.tsym.equals(lambdaIdent.sym.owner)) {
+                                            // Transform outer
instance variable references anchoring them to the captured synthetic.
+                                            Symbol tSym = m.get(out);
+                                            JCExpression t =
make.Ident(tSym).setType(lambdaIdent.sym.owner.type);
+
tSym.setTypeAttributes(lambdaIdent.sym.owner.getRawTypeAttributes());
+                                            t = make.Select(t,
lambdaIdent.name);
+                                            t.setType(lambdaIdent.type);
+                                            TreeInfo.setSymbol(t,
lambdaIdent.sym);
+                                            return t;
+                                        }
+                                    }
+                                }
                             }
                             break;
                     }


On 1 August 2017 at 14:15, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>
> Thanks Andrey.
>
> I'll take a look in the coming week and let you know of any feedback.
>
> Srikanth
>
>
> On Monday 31 July 2017 08:00 PM, Andrey Petushkov wrote:
>
> Dear Compiler Team,
>
> We?ve occasionally found out that there is a problem in javac related to
> lambda support, in part related to referencing the outer?s entity which
> otherwise would be captured by using inner this, but cannot be since it?s
> not yet fully initialized. More specifically this seem to be omission in the
> fix for JDK-8129740:
> it's fix works fine if it deals with the entity from the outer class(es),
> but fails if the entity is inherited from outer?s parent. Consider the
> following source code:
>
> A.java
> public class A {
>     public boolean test(){
>         return true;
>     }
>     class AA{
>         public AA(Condition condition) {
>         }
>     }
> }
>
> Condition.java
> public interface Condition<T> {
>     boolean check(T t);
> }
>
> B.java
> public class B extends A {
>     private final BA myBA;
>     public B() {
>         myBA = new BA();
>     }
>     public class BA extends AA{
>         public BA() {
>             super(o -> test());
>         }
>     }
>     public static void main(String[] args) {
>         B b = new B();
>         System.out.println(b);
>     }
> }
>
>
> source compiles but execution of B fails with:
> Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>   Location:
>     B$BA.lambda$new$0(LB;Ljava/lang/Object;)Z @1: getfield
>   Reason:
>     Type 'B' (current frame, stack[0]) is not assignable to 'B$BA'
>   Current Frame:
>     bci: @1
>     flags: { }
>     locals: { 'B', 'java/lang/Object' }
>     stack: { 'B' }
>   Bytecode:
>     0x0000000: 2ab4 0001 b600 04ac
>
> at B.<init>(B.java:6)
> at B.main(B.java:17)
>
> The problem is reproduced on both latest 8u and 9 (by the time of the bug
> submission)
>
> My naive attempt to fix could be seen here
> http://cr.openjdk.java.net/~apetushkov/8184989/webrev/ (based on latest 8u)
> Please could you consider reviewing/improving it or suggesting improvement
> direction as appropriate
>
> Thanks,
> Andrey
>
>

From huaming.li at oracle.com  Thu Aug  3 09:43:46 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 3 Aug 2017 17:43:46 +0800
Subject: (10) RFR of JDK-8185788: langtools test
 jdk/javadoc/doclet/testModules/TestModuleServicesLink.java fails with
 compilation error
Message-ID: <4ba24f2b-b78c-cc4d-a431-ef589ecbfdd1@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8185788

webrev: http://cr.openjdk.java.net/~mli/8185788/webrev.00/


Thank you

-Hamlin


From jonathan.gibbons at oracle.com  Thu Aug  3 15:25:58 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 3 Aug 2017 08:25:58 -0700
Subject: (10) RFR of JDK-8185788: langtools test
 jdk/javadoc/doclet/testModules/TestModuleServicesLink.java fails with
 compilation error
In-Reply-To: <4ba24f2b-b78c-cc4d-a431-ef589ecbfdd1@oracle.com>
References: <4ba24f2b-b78c-cc4d-a431-ef589ecbfdd1@oracle.com>
Message-ID: <1a2a0697-6fe7-df65-aa13-60debb7b9d51@oracle.com>

Hamlin,

OK, but it would be better to put the two new entries first in the list, 
not last (i.e. in alphabetical order.)  Do that and you're good to go.

-- Jon


On 8/3/17 2:43 AM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8185788
>
> webrev: http://cr.openjdk.java.net/~mli/8185788/webrev.00/
>
>
> Thank you
>
> -Hamlin
>


From bsrbnd at gmail.com  Thu Aug  3 21:32:06 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 3 Aug 2017 23:32:06 +0200
Subject: RFR: JDK-8184989. Incorrect class file created when passing
 lambda in inner class constructor and outer is subclass
In-Reply-To: <CAEgw74DFonL=NL1ovQa+yZ4kM0Vo+ZkR1EdMfTxYXpc26tCG5w@mail.gmail.com>
References: <B713E33A-9515-42CD-9029-5EF0A927F33C@gmail.com>
 <598070F0.5070404@oracle.com>
 <CAEgw74DFonL=NL1ovQa+yZ4kM0Vo+ZkR1EdMfTxYXpc26tCG5w@mail.gmail.com>
Message-ID: <CAEgw74AXnPsfmmnjCVmLC6EA9mcAKY1Uw=iud7g9b2tJrEmnPQ@mail.gmail.com>

Looking closer at this patch, I think that simply looping on the
key-set could fail in some cases.
Consider the following example:

class A {
    public boolean test(){
        return true;
    }
    class AA{
        public AA(Condition<AA> condition) {
            System.out.println("? " + condition.check(this));
        }
    }
}

interface Condition<T> {
    boolean check(T t);
}

public class B extends A {
    public boolean test() {return false;}
    public void b() {}

    class C extends A {
        public class BA extends AA {
            public BA() {
                super(o -> {b(); return test();});
            }
        }
    }
    public static void main(String[] args) {
        new B().new C().new BA();
    }
}

The invocation of b() implies a proxy to B and the invocation of
test() involves a proxy to C.
But the simple loop on the key-set chooses the first proxy to B for
the invocation of test() and our example prints "false" instead of
"true".

I suggest the following improvement of the loop that chooses the
innermost proxy.
What do you think of that?

Thanks,
Bernard

diff -r 43a83431f19d
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
   Wed Mar 15 15:46:43 2017 +0100
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
   Thu Aug 03 23:03:08 2017 +0200
@@ -2103,9 +2103,22 @@
                             }
                             break;
                         case CAPTURED_OUTER_THIS:
-                            if (lambdaIdent.sym.owner.kind == TYP &&
m.containsKey(lambdaIdent.sym.owner)) {
+                            ClassSymbol proxy = null;
+                            if (lambdaIdent.sym.owner.kind == TYP) {
+                                for (Symbol out: m.keySet()) {
+                                    for (Type type = out.type;
+                                            type.hasTag(CLASS) &&
!type.isErroneous();
+
type=((ClassSymbol)type.tsym).getSuperclass()) {
+                                        if
(type.tsym.equals(lambdaIdent.sym.owner)
+                                                && (proxy == null ||
out.isEnclosedBy(proxy))) {
+                                            proxy = (ClassSymbol)out;
+                                        }
+                                    }
+                                }
+                            }
+                            if (proxy != null) {
                                 // Transform outer instance variable
references anchoring them to the captured synthetic.
-                                Symbol tSym = m.get(lambdaIdent.sym.owner);
+                                Symbol tSym = m.get(proxy);
                                 JCExpression t =
make.Ident(tSym).setType(lambdaIdent.sym.owner.type);

tSym.setTypeAttributes(lambdaIdent.sym.owner.getRawTypeAttributes());
                                 t = make.Select(t, lambdaIdent.name);


On 2 August 2017 at 15:02, B. Blaser <bsrbnd at gmail.com> wrote:
> Andrey, Srikanth, All,
>
> At first sight, this looks good to me.
>
> I would perhaps rewrite it as here under, to be more expressive.
> I did it rapidly on a quite old jdk9 revision (sorry...), but this
> should work on the latest, too.
>
> What do you think of this rewriting?
>
> Regards,
> Bernard
>
> diff -r 43a83431f19d
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>    Wed Mar 15 15:46:43 2017 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>    Wed Aug 02 14:11:08 2017 +0200
> @@ -2103,15 +2103,23 @@
>                              }
>                              break;
>                          case CAPTURED_OUTER_THIS:
> -                            if (lambdaIdent.sym.owner.kind == TYP &&
> m.containsKey(lambdaIdent.sym.owner)) {
> -                                // Transform outer instance variable
> references anchoring them to the captured synthetic.
> -                                Symbol tSym = m.get(lambdaIdent.sym.owner);
> -                                JCExpression t =
> make.Ident(tSym).setType(lambdaIdent.sym.owner.type);
> -
> tSym.setTypeAttributes(lambdaIdent.sym.owner.getRawTypeAttributes());
> -                                t = make.Select(t, lambdaIdent.name);
> -                                t.setType(lambdaIdent.type);
> -                                TreeInfo.setSymbol(t, lambdaIdent.sym);
> -                                return t;
> +                            if (lambdaIdent.sym.owner.kind == TYP) {
> +                                for (Symbol out: m.keySet()) {
> +                                    for (Type type = out.type;
> +                                            type.hasTag(CLASS) &&
> !type.isErroneous();
> +
> type=((ClassSymbol)type.tsym).getSuperclass()) {
> +                                        if
> (type.tsym.equals(lambdaIdent.sym.owner)) {
> +                                            // Transform outer
> instance variable references anchoring them to the captured synthetic.
> +                                            Symbol tSym = m.get(out);
> +                                            JCExpression t =
> make.Ident(tSym).setType(lambdaIdent.sym.owner.type);
> +
> tSym.setTypeAttributes(lambdaIdent.sym.owner.getRawTypeAttributes());
> +                                            t = make.Select(t,
> lambdaIdent.name);
> +                                            t.setType(lambdaIdent.type);
> +                                            TreeInfo.setSymbol(t,
> lambdaIdent.sym);
> +                                            return t;
> +                                        }
> +                                    }
> +                                }
>                              }
>                              break;
>                      }
>
>
> On 1 August 2017 at 14:15, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>
>> Thanks Andrey.
>>
>> I'll take a look in the coming week and let you know of any feedback.
>>
>> Srikanth
>>
>>
>> On Monday 31 July 2017 08:00 PM, Andrey Petushkov wrote:
>>
>> Dear Compiler Team,
>>
>> We?ve occasionally found out that there is a problem in javac related to
>> lambda support, in part related to referencing the outer?s entity which
>> otherwise would be captured by using inner this, but cannot be since it?s
>> not yet fully initialized. More specifically this seem to be omission in the
>> fix for JDK-8129740:
>> it's fix works fine if it deals with the entity from the outer class(es),
>> but fails if the entity is inherited from outer?s parent. Consider the
>> following source code:
>>
>> A.java
>> public class A {
>>     public boolean test(){
>>         return true;
>>     }
>>     class AA{
>>         public AA(Condition condition) {
>>         }
>>     }
>> }
>>
>> Condition.java
>> public interface Condition<T> {
>>     boolean check(T t);
>> }
>>
>> B.java
>> public class B extends A {
>>     private final BA myBA;
>>     public B() {
>>         myBA = new BA();
>>     }
>>     public class BA extends AA{
>>         public BA() {
>>             super(o -> test());
>>         }
>>     }
>>     public static void main(String[] args) {
>>         B b = new B();
>>         System.out.println(b);
>>     }
>> }
>>
>>
>> source compiles but execution of B fails with:
>> Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
>> Exception Details:
>>   Location:
>>     B$BA.lambda$new$0(LB;Ljava/lang/Object;)Z @1: getfield
>>   Reason:
>>     Type 'B' (current frame, stack[0]) is not assignable to 'B$BA'
>>   Current Frame:
>>     bci: @1
>>     flags: { }
>>     locals: { 'B', 'java/lang/Object' }
>>     stack: { 'B' }
>>   Bytecode:
>>     0x0000000: 2ab4 0001 b600 04ac
>>
>> at B.<init>(B.java:6)
>> at B.main(B.java:17)
>>
>> The problem is reproduced on both latest 8u and 9 (by the time of the bug
>> submission)
>>
>> My naive attempt to fix could be seen here
>> http://cr.openjdk.java.net/~apetushkov/8184989/webrev/ (based on latest 8u)
>> Please could you consider reviewing/improving it or suggesting improvement
>> direction as appropriate
>>
>> Thanks,
>> Andrey
>>
>>

From cushon at google.com  Sat Aug  5 01:16:02 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 4 Aug 2017 18:16:02 -0700
Subject: question about JDK-8063054 (incorrect raw type warnings for
 method references)
In-Reply-To: <fb08f689-fc86-d0a6-77af-1cd54de2e026@oracle.com>
References: <CAL4QsgspYYL6HNYm9zjoCdk6=AzTh_ohqfFPXPRUd6qAnHsV1g@mail.gmail.com>
 <532edc20-8715-4b17-15a0-36b99f23bed9@oracle.com>
 <CAEgw74BVhg_Wv1DtC9ArKCYqu+JmwZZQaf+Z_+7yMMuWWeDDxA@mail.gmail.com>
 <CAEgw74AjVWWRKg0Kok5PDFXM3s1t5OekFkS1Pa+Cwk7qttNeig@mail.gmail.com>
 <9ad253e7-30bc-f574-8f77-25ca406e5bf6@oracle.com>
 <CAEgw74AKDoohtaZDMG83ZHQDBfZHThNz0kbtf5Ng9gu8=S82EQ@mail.gmail.com>
 <fb08f689-fc86-d0a6-77af-1cd54de2e026@oracle.com>
Message-ID: <CAL4QsguseBsf5_MAJEMJH3R8NwVvrvyFC6qGW7Fs=xuyj=LkmA@mail.gmail.com>

Friendly ping - it doesn't look like this fix ever got merged. Did you run
into problems with the approach?

On Fri, Mar 24, 2017 at 9:26 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
>
> On 24/03/17 15:56, B. Blaser wrote:
>
>> Hi Maurizio,
>>
>> On 23 March 2017 at 12:58, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>>> Hi Bernard,
>>>
>>> [...]
>>>
>>> I think the lines in bold are the ones we need to pay attention to; in
>>> other
>>> words, if the receiver type is raw and the type of the first search is
>>> identical to the type of the second search, then it means no inference
>>> occurred. I think something like this could easily be achieved w/o any
>>> visitors, with something like this:
>>>
>>>                  if (that.getMode() == ReferenceMode.INVOKE &&
>>>                          TreeInfo.isStaticSelector(that.expr, names) &&
>>>                          that.kind.isUnbound() &&
>>>                          types.isSameTypes(lookupHelper.site,
>>> that.expr.type)
>>> {
>>>                      chk.checkRaw(that.expr, localEnv);
>>>                  }
>>>
>>> I did some quick tests and this simple patch seems to remove the
>>> undesired
>>> warnings in the examples we have seen so far, but retains them where they
>>> are truly deserved. What do you think?
>>>
>>> Maurizio
>>>
>> Fine, nice solution... I would simply rewrite it as follows (
>> lookupHelper.site.isRaw() ):
>>
>>                  if (that.getMode() == ReferenceMode.INVOKE &&
>>                          TreeInfo.isStaticSelector(that.expr, names) &&
>>                          that.kind.isUnbound() &&
>>                          lookupHelper.site.isRaw()) {
>>                      chk.checkRaw(that.expr, localEnv);
>>                  }
>>
>> This would avoid some redundant checks if "ReferenceType" isn't raw (I
>> think), for example:
>>
>> class Test10 {
>>      interface Consumer<T> { void accept(T arg); }
>>      interface Parent<P> { void foo(); }
>>      interface Child extends Parent<String> {}
>>      static <T> void m(T arg, Consumer<T> f) {}
>>      public void test(Child c) { m(c, Parent<String>::foo); }
>> }
>>
>> Here, "types.isSameType(lookupHelper.site, that.expr.type)" would
>> verify if "Parent<String> == Parent<String>" and then "chk.checkRaw()"
>> would check if "Parent<String>" is raw...
>>
>> But, at first sight, this looks good. I'll try to do some more testing...
>>
>> What do you think of this small rewriting?
>>
> Yeah - I think that could work too (not that I'm too worried about
> performances here - we're outside overload resolution at this stage).
>
> Maurizio
>
>>
>> Bernard
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170804/833f446d/attachment.html>

From maurizio.cimadamore at oracle.com  Sat Aug  5 05:19:29 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 4 Aug 2017 22:19:29 -0700
Subject: question about JDK-8063054 (incorrect raw type warnings for
 method references)
In-Reply-To: <CAL4QsguseBsf5_MAJEMJH3R8NwVvrvyFC6qGW7Fs=xuyj=LkmA@mail.gmail.com>
References: <CAL4QsgspYYL6HNYm9zjoCdk6=AzTh_ohqfFPXPRUd6qAnHsV1g@mail.gmail.com>
 <532edc20-8715-4b17-15a0-36b99f23bed9@oracle.com>
 <CAEgw74BVhg_Wv1DtC9ArKCYqu+JmwZZQaf+Z_+7yMMuWWeDDxA@mail.gmail.com>
 <CAEgw74AjVWWRKg0Kok5PDFXM3s1t5OekFkS1Pa+Cwk7qttNeig@mail.gmail.com>
 <9ad253e7-30bc-f574-8f77-25ca406e5bf6@oracle.com>
 <CAEgw74AKDoohtaZDMG83ZHQDBfZHThNz0kbtf5Ng9gu8=S82EQ@mail.gmail.com>
 <fb08f689-fc86-d0a6-77af-1cd54de2e026@oracle.com>
 <CAL4QsguseBsf5_MAJEMJH3R8NwVvrvyFC6qGW7Fs=xuyj=LkmA@mail.gmail.com>
Message-ID: <f93af643-99b9-793f-5db3-55c76d9fe021@oracle.com>

You are right - I think we've got distracted by other things. I will 
make sure this makes into the jdk10 repo.

Cheers
Maurizio


On 04/08/17 18:16, Liam Miller-Cushon wrote:
> Friendly ping - it doesn't look like this fix ever got merged. Did you 
> run into problems with the approach?
>
> On Fri, Mar 24, 2017 at 9:26 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>
>     On 24/03/17 15:56, B. Blaser wrote:
>
>         Hi Maurizio,
>
>         On 23 March 2017 at 12:58, Maurizio Cimadamore
>         <maurizio.cimadamore at oracle.com
>         <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>             Hi Bernard,
>
>             [...]
>
>             I think the lines in bold are the ones we need to pay
>             attention to; in other
>             words, if the receiver type is raw and the type of the
>             first search is
>             identical to the type of the second search, then it means
>             no inference
>             occurred. I think something like this could easily be
>             achieved w/o any
>             visitors, with something like this:
>
>                              if (that.getMode() == ReferenceMode.INVOKE &&
>              TreeInfo.isStaticSelector(that.expr, names) &&
>                                      that.kind.isUnbound() &&
>              types.isSameTypes(lookupHelper.site, that.expr.type)
>             {
>                                  chk.checkRaw(that.expr, localEnv);
>                              }
>
>             I did some quick tests and this simple patch seems to
>             remove the undesired
>             warnings in the examples we have seen so far, but retains
>             them where they
>             are truly deserved. What do you think?
>
>             Maurizio
>
>         Fine, nice solution... I would simply rewrite it as follows (
>         lookupHelper.site.isRaw() ):
>
>                          if (that.getMode() == ReferenceMode.INVOKE &&
>                                  TreeInfo.isStaticSelector(that.expr,
>         names) &&
>                                  that.kind.isUnbound() &&
>                                  lookupHelper.site.isRaw()) {
>                              chk.checkRaw(that.expr, localEnv);
>                          }
>
>         This would avoid some redundant checks if "ReferenceType"
>         isn't raw (I
>         think), for example:
>
>         class Test10 {
>              interface Consumer<T> { void accept(T arg); }
>              interface Parent<P> { void foo(); }
>              interface Child extends Parent<String> {}
>              static <T> void m(T arg, Consumer<T> f) {}
>              public void test(Child c) { m(c, Parent<String>::foo); }
>         }
>
>         Here, "types.isSameType(lookupHelper.site, that.expr.type)" would
>         verify if "Parent<String> == Parent<String>" and then
>         "chk.checkRaw()"
>         would check if "Parent<String>" is raw...
>
>         But, at first sight, this looks good. I'll try to do some more
>         testing...
>
>         What do you think of this small rewriting?
>
>     Yeah - I think that could work too (not that I'm too worried about
>     performances here - we're outside overload resolution at this stage).
>
>     Maurizio
>
>
>         Bernard
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170804/3d01861a/attachment.html>

From bsrbnd at gmail.com  Fri Aug 25 06:48:30 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 25 Aug 2017 08:48:30 +0200
Subject: JDK 8159439: NPEForModuleInfoWithNonZeroSuperClassTest updated
In-Reply-To: <CAEgw74Bv4EdzQ7LcN=YngyEKDBuCB43fDBbeYi8fiG84BiS3MA@mail.gmail.com>
References: <CAEgw74CEU7APkbKD11ph3JxU57HEXNKWFvGSQ=G=8nDcd9Y-6Q@mail.gmail.com>
 <451d2055-f578-3632-ed3d-efd4fd4f2a32@oracle.com>
 <8d2865eb-f643-b382-f61d-d84dc3438c1b@oracle.com>
 <CAEgw74Bv4EdzQ7LcN=YngyEKDBuCB43fDBbeYi8fiG84BiS3MA@mail.gmail.com>
Message-ID: <CAEgw74BnkiNx7as4AcATF_UgHad+gX5Dec5quzcprWGJh2G-LA@mail.gmail.com>

Hi,

On 17 March 2017 at 14:40, B. Blaser <bsrbnd at gmail.com> wrote:
> On 16 March 2017 at 23:23, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>> On 16/03/17 15:23, Jonathan Gibbons wrote:
>>>
>>> It sounds like build.xml should be updated to use the problem list.
>>>
>>> I don't how how common it is to use that target, which is probably
>>> why this has slipped through.
>>
>> My bad - I did not update the target to use the problem list file when I
>> wrote the new modularized ant build. I will look into this (for 10).

Did you already look at that or should I create a JBS issue?

Bernard

>> Maurizio
>
> Great!
>
> I also had to include a "pathelement" to "asmtools.jar" as below
> (which could eventually be pushed to 9 as it seems harmless). The
> "timeoutFactor" isn't absolutely necessary but useful when the tests
> are run on a slower CPU.
>
> Bernard
>
> diff --git a/make/build.xml b/make/build.xml
> --- a/make/build.xml
> +++ b/make/build.xml
> @@ -332,6 +332,7 @@
>              <classpath>
>                  <pathelement location="${jtreg.home}/lib/jtreg.jar"/>
>                  <pathelement location="${jtreg.home}/lib/javatest.jar"/>
> +                <pathelement location="${jtreg.home}/lib/asmtools.jar"/>
>              </classpath>
>          </taskdef>
>          <macrodef name="jtreg-tool">
> @@ -359,6 +360,7 @@
>                      agentvm="@{agentvm}" verbose="@{verbose}"
>                      failonerror="false" resultproperty="jtreg.@{name}.result"
>                      vmoptions="${coverage.options} @{extra.jvmargs}
> ${xpatch.noquotes.cmd}">
> +                    <arg value="-timeoutFactor:5"/>
>                      <arg value="-debug:@{jpda.jvmargs}"/>
>                      <arg line="@{keywords}"/>
>                      <arg line="@{options}"/>
>
>>> If the test can be fixed and removed from the problem list, that
>>> would be good.
>>>
>>> -- Jon
>>>
>>>
>>> On 3/16/17 5:20 AM, B. Blaser wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've noticed that running the javac tests using the "jtreg" target of
>>>> "build.xml" seems not to take care of the "ProblemList.txt" (is this
>>>> normal?). For example,
>>>>
>>>> tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.java
>>>> is run and fails (but not with the expected output)...
>>>>
>>>> Nevertheless, the reason why it's on the problem list seems to be
>>>> outdated as asmtools 6.0 includes the module handling. But a recent
>>>> change in com.sun.tools.javac.jvm.ModuleNameReader.readModuleName()
>>>> checks the "super_class" field when reading the module name. Which
>>>> makes this test fail with another message as the expected one.
>>>>
>>>> I think this test could probably be removed from the "ProblemList.txt"
>>>> and the expected output updated as below. Any comment is welcome.
>>>>
>>>> Thanks,
>>>> Bernard
>>>>
>>>> diff --git
>>>> a/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>>
>>>> b/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>> ---
>>>> a/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>> +++
>>>> b/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>> @@ -1,2 +1,2 @@
>>>> -- compiler.err.cant.access: mod.module-info,
>>>> (compiler.misc.bad.class.file.header: module-info.class,
>>>> (compiler.misc.module.info.invalid.super.class))
>>>> +- compiler.err.cant.access: <error>.module-info,
>>>> (compiler.misc.bad.class.file.header: module-info.class,
>>>> (compiler.misc.module.name.mismatch: mod/module-info, <error>))
>>>>   1 error
>>>
>>>
>>

From bsrbnd at gmail.com  Fri Aug 25 07:09:05 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 25 Aug 2017 09:09:05 +0200
Subject: [PATCH] 8036827: Incorrect printing of the generic method
 declaration
In-Reply-To: <CAEgw74BiwW=APYoLr-HsdVsGAvzE1FidPxWRmYcePHemsg+kUQ@mail.gmail.com>
References: <CAEgw74ATJpabgeE7JSq3SdhrFRXj8XH38rJj7OE5oLqaf4d4aA@mail.gmail.com>
 <CAEgw74DXs4ZWUptuciXp7QcPhsSqVp7NCeOAa6tf_OQpeB4YsA@mail.gmail.com>
 <588A68F3.70801@oracle.com>
 <CAEgw74CBEPTEDiKAoB_0=1VLAeMxdkmpA4SG8wxb1wGhczD68A@mail.gmail.com>
 <CAEgw74BiwW=APYoLr-HsdVsGAvzE1FidPxWRmYcePHemsg+kUQ@mail.gmail.com>
Message-ID: <CAEgw74AaXbLv2ahd4p6aYYhMrX4R9bLq=YqsHy_haw1PJqnraQ@mail.gmail.com>

Jon,

On 28 January 2017 at 19:26, B. Blaser <bsrbnd at gmail.com> wrote:
> Jonathan,
>
> 2017-01-27 23:05 GMT+01:00 B. Blaser <bsrbnd at gmail.com>:
>> Thanks for your answer.
>> It seems reasonable to print it and compliant with the comments you
>> provided in JDK 7031005.
>>
>> I think there's probably a slight inconsistency similar to JDK
>> 7031005, but for classes.
>> With -verbose, we have:
>>
>> 1) Info from super_class:
>>
>> $ more JDK_8036827.java
>> class JDK_8036827 {}
>>
>> $ javap -v JDK_8036827.class
>>   Compiled from "JDK_8036827.java"
>> class JDK_8036827
>>
>> 2) Info from class signature:
>>
>> $ more JDK_8036827.java
>> class JDK_8036827<T> {}
>>
>> $ javap -v JDK_8036827.class
>>   Compiled from "JDK_8036827.java"
>> class JDK_8036827<T extends java.lang.Object> extends java.lang.Object
>>
>> What's the correct expectation?
>>
>> Should "extends java.lang.Object" be present in the first example as
>> this information is present in the class file?
>
> If so, I suggest the following fix along with the associate test
> updated to check the -verbose behavior.

Should I create a JBS issue for that?

Bernard

> Bernard
>
> diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2007, 2017, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -205,7 +205,7 @@
>              // use info from class file header
>              if (classFile.isClass() && classFile.super_class != 0 ) {
>                  String sn = getJavaSuperclassName(cf);
> -                if (!sn.equals("java.lang.Object")) {
> +                if (options.verbose || !sn.equals("java.lang.Object")) {
>                      print(" extends ");
>                      print(sn);
>                  }
> diff --git a/test/tools/javap/TestSuperclass.java
> b/test/tools/javap/TestSuperclass.java
> --- a/test/tools/javap/TestSuperclass.java
> +++ b/test/tools/javap/TestSuperclass.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -53,12 +53,14 @@
>      }
>
>      enum GenericKind {
> -        NO(""),
> -        YES("<T>");
> -        GenericKind(String typarams) {
> +        NO("", ""),
> +        YES("<T>", "<T extends java.lang.Object>");
> +        GenericKind(String typarams, String verbose) {
>              this.typarams = typarams;
> +            this.verbose = verbose;
>          }
>          final String typarams;
> +        final String verbose;
>      }
>
>      enum SuperKind {
> @@ -73,6 +75,9 @@
>          String decl(ClassKind ck) {
>              return (name == null) ? "" : ck.keyword + " " + name + " { }";
>          }
> +        String verbose(ClassKind ck) {
> +            return ck == ClassKind.CLASS && name == null ? "extends
> java.lang.Object" : extend();
> +        }
>          final String name;
>      }
>
> @@ -117,28 +122,41 @@
>              throw new Error("compilation failed");
>
>          File testClass = new File(testDir, "Test.class");
> -        String out = javap(testClass);
> +
> +        System.err.print("normal: ");
> +        String out = javap(testClass.getPath());
>
>          // Extract class sig from first line of Java source
>          String expect = js.source.replaceAll("(?s)^(.* Test[^{]+?)
> *\\{.*", "$1");
>
>          // Extract class sig from line from javap output
>          String found = out.replaceAll("(?s).*\n(.* Test[^{]+?) *\\{.*", "$1");
> +        System.err.println(found);
>
>          checkEqual("class signature", expect, found);
>
> +        System.err.print("verbose: ");
> +        out = javap("-v", testClass.getPath());
> +
> +        String verbose = ck.keyword + " Test" + gk.verbose +
> +                (sk.verbose(ck).isEmpty() ? "" : " " + sk.verbose(ck));
> +
> +        if (out.contains(verbose))
> +            System.err.println(verbose);
> +        else
> +            checkEqual("class signature", verbose, out);
> +
> +        System.err.println();
> +
>          return errors;
>      }
>
> -    String javap(File file) {
> +    String javap(String... args) {
>          StringWriter sw = new StringWriter();
>          PrintWriter pw = new PrintWriter(sw);
> -        String[] args = { file.getPath() };
>          int rc = com.sun.tools.javap.Main.run(args, pw);
>          pw.close();
>          String out = sw.toString();
> -        if (!out.isEmpty())
> -            System.err.println(out);
>          if (rc != 0)
>              throw new Error("javap failed: rc=" + rc);
>          return out;
>
>
>> 2017-01-26 22:24 GMT+01:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>>> Bernard,
>>>
>>> I don't think this should be changed, and I will close out the JBS issue.
>>>
>>> Without the -verbose flag, the "extends java.lang.Object" is not printed.
>>>
>>> $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/javap
>>> play/src/JDK_8036827.class
>>> Compiled from "JDK_8036827.java"
>>> class JDK_8036827 {
>>>   JDK_8036827();
>>>   public <T> T m1(T);
>>> }
>>>
>>> When the -verbose flag is used, it does not seem unreasonable to print out
>>> information which is explicitly present in the class file.
>>>
>>> -- Jon

From bsrbnd at gmail.com  Fri Aug 25 07:23:15 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 25 Aug 2017 09:23:15 +0200
Subject: Incoherent invocation type inference?
In-Reply-To: <CAEgw74D2zs-2pmhCHMPbch65nWSU-_sBd5hYC2NQnSo09vrQ4g@mail.gmail.com>
References: <CAEgw74D9PYSJ+WzAXEHrJwjH6sMqPDQMVOaSng=GGuO+Jmdn2Q@mail.gmail.com>
 <c967bd1b-fb64-abbe-0843-cf62fc5cfeaa@oracle.com>
 <CAEgw74AyezzXH1aef77zF7aOj0JMN1+7UiWkg-Ee-wdHRPdv1A@mail.gmail.com>
 <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com>
 <CAEgw74BvJmpxL3D7c+nBk2VoO0du2Y_mXp9SBvsoO25jvrKo7Q@mail.gmail.com>
 <CAEgw74D8xdm_4uUsOVkX7QPNrCYddLF6s5jyYoDzQs8zOYtkQg@mail.gmail.com>
 <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr>
 <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com>
 <CAEgw74DQLN02rZbGn_p4Ut8yeZU2OwkGzibEXY0AdyN3D+Tpbw@mail.gmail.com>
 <bd1eeaf3-816d-ee9b-4ec8-c16ae7bed81d@oracle.com>
 <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com>
 <CAEgw74Dw=x07g2WY1KmK3H=YrbVB0k6x5aW5=vGOOKaAQOtoFA@mail.gmail.com>
 <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com>
 <CAEgw74Ay2vdtPXZ-0Ai0z228zGAin5=LQdr42-gTKsjqdOS8dA@mail.gmail.com>
 <CAEgw74AiF772dkvmtFwAkwEfQBHVJgFEkpTx63qTJscwmO9TaA@mail.gmail.com>
 <6ab2395d-ffd3-8437-2c57-a93d357e3c15@oracle.com>
 <CAEgw74D2zs-2pmhCHMPbch65nWSU-_sBd5hYC2NQnSo09vrQ4g@mail.gmail.com>
Message-ID: <CAEgw74DB_mR35JqwFczGnj1mKV=dWgnrFcTMHkDmrOjqpfoG_Q@mail.gmail.com>

Maurizio,

On 22 January 2017 at 17:26, B. Blaser <bsrbnd at gmail.com> wrote:
> Hi,
>
> 2017-01-19 18:22 GMT+01:00 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
>> Not sure about your proposed patch.
>>
>> To me the warning should be a property of the method declaration, not of the
>> specific inference.
>>
>> If a method returns a naked type-variable which is not mentioned anywhere in
>> the method parameter types -> Lint warning (not an unchecked warning - just
>> an optional Lint one - category TBD).
>>
>> It's true that, by looking at the callsite, you can also warn for clients
>> passing 'null' arguments, but the extra benefit is not worth the extra
>> complexity IMHO. And, I think this is a problem of bad API, not one of bad
>> clients. A well-designed API should not have any methods that match the
>> criteria stated above - as their behavior would ultimately be at the
>> client's mercy.
>>
>> Maurizio
>
> Here under is a suggestion for the implementation of the rule you
> stated above (Attr.visitMethodDef(), upon rev. b6960e2da008).
>
> I kept a check on the callsite for further evaluation (in
> Attr.checkMethod() to be more general). I think both are
> complementary.
>
> "<T> T[] List.toArray(T[])" is a good example of a well designed API.
> But an invocation of the form "a = l.toArray(null)" is dangerous due
> to the obvious API's lack of control over T and might be warned.
>
> For the Lint category, I suggest to name it "generic" and to use it
> for warnings about type variables. Other checks like the "final" one
> could fall into the same category.
>
> Does this look better?

Should I create a JBS issue for that?

Bernard

> Thanks,
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
> @@ -268,6 +268,11 @@
>          UNCHECKED("unchecked"),
>
>          /**
> +         * Warn about issues relating to type variables.
> +         */
> +        GENERIC("generic"),
> +
> +        /**
>           * Warn about potentially unsafe vararg methods
>           */
>          VARARGS("varargs");
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -947,6 +947,7 @@
>              deferredLintHandler.flush(tree.pos());
>              chk.checkDeprecatedAnnotation(tree.pos(), m);
>
> +            chk.checkGenMethDeclaration(tree.pos(), m);
>
>              // Create a new environment with local scope
>              // for attributing the method.
> @@ -3918,6 +3919,8 @@
>                              final List<JCExpression> argtrees,
>                              List<Type> argtypes,
>                              List<Type> typeargtypes) {
> +        chk.checkGenMethInvocation(env.tree.pos(), sym, resultInfo, argtypes);
> +
>          // Test (5): if symbol is an instance method of a raw type, issue
>          // an unchecked warning if its argument types change under erasure.
>          if ((sym.flags() & STATIC) == 0 &&
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> @@ -3876,4 +3876,76 @@
>          }
>      }
>
> +    // Check the declaration's precision for type variables.
> +    void checkGenMethDeclaration(DiagnosticPosition pos, Symbol sym) {
> +        if (sym.type.hasTag(FORALL)) {
> +            ForAll gmt = (ForAll)sym.type;
> +            MethodType mt = (MethodType)gmt.qtype;
> +            List<Type> tvars = gmt.tvars;
> +
> +            Type elemResType = mt.restype;
> +            while (elemResType.hasTag(ARRAY)) {
> +                elemResType = ((ArrayType)elemResType).elemtype;
> +            }
> +            if (elemResType.hasTag(TYPEVAR) && tvars.contains(elemResType)) {
> +                boolean ok = false;
> +                for (Type t: mt.argtypes) {
> +                    if (t.contains(elemResType))
> +                        ok = true;
> +                }
> +                if (!ok)
> +                    warnGeneric(
> +                            pos,
> +                            "generic.imprecise.method.declaration",
> +                            Kinds.kindName(sym),
> +                            sym.name,
> +                            Kinds.kindName(sym.location()),
> +                            sym.location(),
> +                            elemResType);
> +            }
> +        }
> +    }
> +
> +    // Check the actual arguments' precision for type variables.
> +    void checkGenMethInvocation(
> +            DiagnosticPosition pos,
> +            Symbol sym,
> +            Attr.ResultInfo resultInfo,
> +            List<Type> argtypes) {
> +
> +        if (sym.type.hasTag(FORALL)) {
> +            ForAll gmt = (ForAll)sym.type;
> +            MethodType mt = (MethodType)gmt.qtype;
> +
> +            Type elemResType = mt.restype;
> +            while (elemResType.hasTag(ARRAY)) {
> +                elemResType = ((ArrayType)elemResType).elemtype;
> +            }
> +            if (resultInfo != null && resultInfo.pt != Type.noType &&
> elemResType.hasTag(TYPEVAR)) {
> +                boolean ok = false;
> +                if (mt.argtypes.length() <= argtypes.length()) {
> +                    for (int i=0; i<mt.argtypes.length(); i++) {
> +                        Type pType = mt.argtypes.get(i);
> +                        Type aType = argtypes.get(i);
> +                        if (pType.contains(elemResType) && aType !=
> syms.botType)
> +                            ok = true;
> +                    }
> +                }
> +                if (!ok)
> +                    warnGeneric(
> +                            pos,
> +                            "generic.imprecise.method.invocation",
> +                            Kinds.kindName(sym),
> +                            sym.name,
> +                            Kinds.kindName(sym.location()),
> +                            sym.location(),
> +                            elemResType);
> +            }
> +        }
> +    }
> +
> +    void warnGeneric(DiagnosticPosition pos, String key, Object... args) {
> +        if (lint.isEnabled(LintCategory.GENERIC))
> +            log.warning(LintCategory.GENERIC, pos, key, args);
> +    }
>  }
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> @@ -1756,6 +1756,14 @@
>  compiler.warn.unchecked.varargs.non.reifiable.type=\
>      Possible heap pollution from parameterized vararg type {0}
>
> +# 0: symbol kind, 1: name, 2: symbol kind, 3: symbol, 4: type
> +compiler.warn.generic.imprecise.method.declaration=\
> +    Imprecise method declaration: parameters of {0} {1} in {2} {3}
> should refer to {4}
> +
> +# 0: symbol kind, 1: name, 2: symbol kind, 3: symbol, 4: type
> +compiler.warn.generic.imprecise.method.invocation=\
> +    Imprecise method invocation: arguments of {0} {1} in {2} {3}
> should refer to {4}
> +
>  # 0: symbol
>  compiler.warn.varargs.unsafe.use.varargs.param=\
>      Varargs method could cause heap pollution from non-reifiable
> varargs parameter {0}
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
> @@ -238,6 +238,9 @@
>  javac.opt.Xlint.desc.unchecked=\
>      Warn about unchecked operations.
>
> +javac.opt.Xlint.desc.generic=\
> +    Warn about issues relating to type variables.
> +
>  javac.opt.Xlint.desc.varargs=\
>      Warn about potentially unsafe vararg methods

From maurizio.cimadamore at oracle.com  Mon Aug 28 12:18:15 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 28 Aug 2017 13:18:15 +0100
Subject: Incoherent invocation type inference?
In-Reply-To: <CAEgw74DB_mR35JqwFczGnj1mKV=dWgnrFcTMHkDmrOjqpfoG_Q@mail.gmail.com>
References: <CAEgw74D9PYSJ+WzAXEHrJwjH6sMqPDQMVOaSng=GGuO+Jmdn2Q@mail.gmail.com>
 <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com>
 <CAEgw74BvJmpxL3D7c+nBk2VoO0du2Y_mXp9SBvsoO25jvrKo7Q@mail.gmail.com>
 <CAEgw74D8xdm_4uUsOVkX7QPNrCYddLF6s5jyYoDzQs8zOYtkQg@mail.gmail.com>
 <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr>
 <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com>
 <CAEgw74DQLN02rZbGn_p4Ut8yeZU2OwkGzibEXY0AdyN3D+Tpbw@mail.gmail.com>
 <bd1eeaf3-816d-ee9b-4ec8-c16ae7bed81d@oracle.com>
 <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com>
 <CAEgw74Dw=x07g2WY1KmK3H=YrbVB0k6x5aW5=vGOOKaAQOtoFA@mail.gmail.com>
 <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com>
 <CAEgw74Ay2vdtPXZ-0Ai0z228zGAin5=LQdr42-gTKsjqdOS8dA@mail.gmail.com>
 <CAEgw74AiF772dkvmtFwAkwEfQBHVJgFEkpTx63qTJscwmO9TaA@mail.gmail.com>
 <6ab2395d-ffd3-8437-2c57-a93d357e3c15@oracle.com>
 <CAEgw74D2zs-2pmhCHMPbch65nWSU-_sBd5hYC2NQnSo09vrQ4g@mail.gmail.com>
 <CAEgw74DB_mR35JqwFczGnj1mKV=dWgnrFcTMHkDmrOjqpfoG_Q@mail.gmail.com>
Message-ID: <5f88a054-d80c-df3d-e76f-a78ec3c9a13e@oracle.com>



On 25/08/17 08:23, B. Blaser wrote:
> Maurizio,
>
> On 22 January 2017 at 17:26, B. Blaser <bsrbnd at gmail.com> wrote:
>> Hi,
>>
>> 2017-01-19 18:22 GMT+01:00 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
>>> Not sure about your proposed patch.
>>>
>>> To me the warning should be a property of the method declaration, not of the
>>> specific inference.
>>>
>>> If a method returns a naked type-variable which is not mentioned anywhere in
>>> the method parameter types -> Lint warning (not an unchecked warning - just
>>> an optional Lint one - category TBD).
>>>
>>> It's true that, by looking at the callsite, you can also warn for clients
>>> passing 'null' arguments, but the extra benefit is not worth the extra
>>> complexity IMHO. And, I think this is a problem of bad API, not one of bad
>>> clients. A well-designed API should not have any methods that match the
>>> criteria stated above - as their behavior would ultimately be at the
>>> client's mercy.
>>>
>>> Maurizio
>> Here under is a suggestion for the implementation of the rule you
>> stated above (Attr.visitMethodDef(), upon rev. b6960e2da008).
>>
>> I kept a check on the callsite for further evaluation (in
>> Attr.checkMethod() to be more general). I think both are
>> complementary.
>>
>> "<T> T[] List.toArray(T[])" is a good example of a well designed API.
>> But an invocation of the form "a = l.toArray(null)" is dangerous due
>> to the obvious API's lack of control over T and might be warned.
>>
>> For the Lint category, I suggest to name it "generic" and to use it
>> for warnings about type variables. Other checks like the "final" one
>> could fall into the same category.
>>
>> Does this look better?
> Should I create a JBS issue for that?
Yes, please, go ahead. I've seen this popping out frequently enough that 
I think it deserves some closure.

Maurizio
>
> Bernard
>
>> Thanks,
>> Bernard
>>
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>> @@ -268,6 +268,11 @@
>>           UNCHECKED("unchecked"),
>>
>>           /**
>> +         * Warn about issues relating to type variables.
>> +         */
>> +        GENERIC("generic"),
>> +
>> +        /**
>>            * Warn about potentially unsafe vararg methods
>>            */
>>           VARARGS("varargs");
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> @@ -947,6 +947,7 @@
>>               deferredLintHandler.flush(tree.pos());
>>               chk.checkDeprecatedAnnotation(tree.pos(), m);
>>
>> +            chk.checkGenMethDeclaration(tree.pos(), m);
>>
>>               // Create a new environment with local scope
>>               // for attributing the method.
>> @@ -3918,6 +3919,8 @@
>>                               final List<JCExpression> argtrees,
>>                               List<Type> argtypes,
>>                               List<Type> typeargtypes) {
>> +        chk.checkGenMethInvocation(env.tree.pos(), sym, resultInfo, argtypes);
>> +
>>           // Test (5): if symbol is an instance method of a raw type, issue
>>           // an unchecked warning if its argument types change under erasure.
>>           if ((sym.flags() & STATIC) == 0 &&
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> @@ -3876,4 +3876,76 @@
>>           }
>>       }
>>
>> +    // Check the declaration's precision for type variables.
>> +    void checkGenMethDeclaration(DiagnosticPosition pos, Symbol sym) {
>> +        if (sym.type.hasTag(FORALL)) {
>> +            ForAll gmt = (ForAll)sym.type;
>> +            MethodType mt = (MethodType)gmt.qtype;
>> +            List<Type> tvars = gmt.tvars;
>> +
>> +            Type elemResType = mt.restype;
>> +            while (elemResType.hasTag(ARRAY)) {
>> +                elemResType = ((ArrayType)elemResType).elemtype;
>> +            }
>> +            if (elemResType.hasTag(TYPEVAR) && tvars.contains(elemResType)) {
>> +                boolean ok = false;
>> +                for (Type t: mt.argtypes) {
>> +                    if (t.contains(elemResType))
>> +                        ok = true;
>> +                }
>> +                if (!ok)
>> +                    warnGeneric(
>> +                            pos,
>> +                            "generic.imprecise.method.declaration",
>> +                            Kinds.kindName(sym),
>> +                            sym.name,
>> +                            Kinds.kindName(sym.location()),
>> +                            sym.location(),
>> +                            elemResType);
>> +            }
>> +        }
>> +    }
>> +
>> +    // Check the actual arguments' precision for type variables.
>> +    void checkGenMethInvocation(
>> +            DiagnosticPosition pos,
>> +            Symbol sym,
>> +            Attr.ResultInfo resultInfo,
>> +            List<Type> argtypes) {
>> +
>> +        if (sym.type.hasTag(FORALL)) {
>> +            ForAll gmt = (ForAll)sym.type;
>> +            MethodType mt = (MethodType)gmt.qtype;
>> +
>> +            Type elemResType = mt.restype;
>> +            while (elemResType.hasTag(ARRAY)) {
>> +                elemResType = ((ArrayType)elemResType).elemtype;
>> +            }
>> +            if (resultInfo != null && resultInfo.pt != Type.noType &&
>> elemResType.hasTag(TYPEVAR)) {
>> +                boolean ok = false;
>> +                if (mt.argtypes.length() <= argtypes.length()) {
>> +                    for (int i=0; i<mt.argtypes.length(); i++) {
>> +                        Type pType = mt.argtypes.get(i);
>> +                        Type aType = argtypes.get(i);
>> +                        if (pType.contains(elemResType) && aType !=
>> syms.botType)
>> +                            ok = true;
>> +                    }
>> +                }
>> +                if (!ok)
>> +                    warnGeneric(
>> +                            pos,
>> +                            "generic.imprecise.method.invocation",
>> +                            Kinds.kindName(sym),
>> +                            sym.name,
>> +                            Kinds.kindName(sym.location()),
>> +                            sym.location(),
>> +                            elemResType);
>> +            }
>> +        }
>> +    }
>> +
>> +    void warnGeneric(DiagnosticPosition pos, String key, Object... args) {
>> +        if (lint.isEnabled(LintCategory.GENERIC))
>> +            log.warning(LintCategory.GENERIC, pos, key, args);
>> +    }
>>   }
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>> @@ -1756,6 +1756,14 @@
>>   compiler.warn.unchecked.varargs.non.reifiable.type=\
>>       Possible heap pollution from parameterized vararg type {0}
>>
>> +# 0: symbol kind, 1: name, 2: symbol kind, 3: symbol, 4: type
>> +compiler.warn.generic.imprecise.method.declaration=\
>> +    Imprecise method declaration: parameters of {0} {1} in {2} {3}
>> should refer to {4}
>> +
>> +# 0: symbol kind, 1: name, 2: symbol kind, 3: symbol, 4: type
>> +compiler.warn.generic.imprecise.method.invocation=\
>> +    Imprecise method invocation: arguments of {0} {1} in {2} {3}
>> should refer to {4}
>> +
>>   # 0: symbol
>>   compiler.warn.varargs.unsafe.use.varargs.param=\
>>       Varargs method could cause heap pollution from non-reifiable
>> varargs parameter {0}
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
>> @@ -238,6 +238,9 @@
>>   javac.opt.Xlint.desc.unchecked=\
>>       Warn about unchecked operations.
>>
>> +javac.opt.Xlint.desc.generic=\
>> +    Warn about issues relating to type variables.
>> +
>>   javac.opt.Xlint.desc.varargs=\
>>       Warn about potentially unsafe vararg methods


From maurizio.cimadamore at oracle.com  Mon Aug 28 12:20:25 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 28 Aug 2017 13:20:25 +0100
Subject: JDK 8159439: NPEForModuleInfoWithNonZeroSuperClassTest updated
In-Reply-To: <CAEgw74BnkiNx7as4AcATF_UgHad+gX5Dec5quzcprWGJh2G-LA@mail.gmail.com>
References: <CAEgw74CEU7APkbKD11ph3JxU57HEXNKWFvGSQ=G=8nDcd9Y-6Q@mail.gmail.com>
 <451d2055-f578-3632-ed3d-efd4fd4f2a32@oracle.com>
 <8d2865eb-f643-b382-f61d-d84dc3438c1b@oracle.com>
 <CAEgw74Bv4EdzQ7LcN=YngyEKDBuCB43fDBbeYi8fiG84BiS3MA@mail.gmail.com>
 <CAEgw74BnkiNx7as4AcATF_UgHad+gX5Dec5quzcprWGJh2G-LA@mail.gmail.com>
Message-ID: <e48c9e1e-6e46-8d5d-36fe-c3c0c6b06823@oracle.com>



On 25/08/17 07:48, B. Blaser wrote:
> Hi,
>
> On 17 March 2017 at 14:40, B. Blaser <bsrbnd at gmail.com> wrote:
>> On 16 March 2017 at 23:23, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>>
>>> On 16/03/17 15:23, Jonathan Gibbons wrote:
>>>> It sounds like build.xml should be updated to use the problem list.
>>>>
>>>> I don't how how common it is to use that target, which is probably
>>>> why this has slipped through.
>>> My bad - I did not update the target to use the problem list file when I
>>> wrote the new modularized ant build. I will look into this (for 10).
> Did you already look at that or should I create a JBS issue?
This has been taken care of as part of JDK-8177667. Please let me know 
if you still have issues.

Maurizio
>
> Bernard
>
>>> Maurizio
>> Great!
>>
>> I also had to include a "pathelement" to "asmtools.jar" as below
>> (which could eventually be pushed to 9 as it seems harmless). The
>> "timeoutFactor" isn't absolutely necessary but useful when the tests
>> are run on a slower CPU.
>>
>> Bernard
>>
>> diff --git a/make/build.xml b/make/build.xml
>> --- a/make/build.xml
>> +++ b/make/build.xml
>> @@ -332,6 +332,7 @@
>>               <classpath>
>>                   <pathelement location="${jtreg.home}/lib/jtreg.jar"/>
>>                   <pathelement location="${jtreg.home}/lib/javatest.jar"/>
>> +                <pathelement location="${jtreg.home}/lib/asmtools.jar"/>
>>               </classpath>
>>           </taskdef>
>>           <macrodef name="jtreg-tool">
>> @@ -359,6 +360,7 @@
>>                       agentvm="@{agentvm}" verbose="@{verbose}"
>>                       failonerror="false" resultproperty="jtreg.@{name}.result"
>>                       vmoptions="${coverage.options} @{extra.jvmargs}
>> ${xpatch.noquotes.cmd}">
>> +                    <arg value="-timeoutFactor:5"/>
>>                       <arg value="-debug:@{jpda.jvmargs}"/>
>>                       <arg line="@{keywords}"/>
>>                       <arg line="@{options}"/>
>>
>>>> If the test can be fixed and removed from the problem list, that
>>>> would be good.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 3/16/17 5:20 AM, B. Blaser wrote:
>>>>> Hi,
>>>>>
>>>>> I've noticed that running the javac tests using the "jtreg" target of
>>>>> "build.xml" seems not to take care of the "ProblemList.txt" (is this
>>>>> normal?). For example,
>>>>>
>>>>> tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.java
>>>>> is run and fails (but not with the expected output)...
>>>>>
>>>>> Nevertheless, the reason why it's on the problem list seems to be
>>>>> outdated as asmtools 6.0 includes the module handling. But a recent
>>>>> change in com.sun.tools.javac.jvm.ModuleNameReader.readModuleName()
>>>>> checks the "super_class" field when reading the module name. Which
>>>>> makes this test fail with another message as the expected one.
>>>>>
>>>>> I think this test could probably be removed from the "ProblemList.txt"
>>>>> and the expected output updated as below. Any comment is welcome.
>>>>>
>>>>> Thanks,
>>>>> Bernard
>>>>>
>>>>> diff --git
>>>>> a/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>>>
>>>>> b/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>>> ---
>>>>> a/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>>> +++
>>>>> b/test/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out
>>>>> @@ -1,2 +1,2 @@
>>>>> -- compiler.err.cant.access: mod.module-info,
>>>>> (compiler.misc.bad.class.file.header: module-info.class,
>>>>> (compiler.misc.module.info.invalid.super.class))
>>>>> +- compiler.err.cant.access: <error>.module-info,
>>>>> (compiler.misc.bad.class.file.header: module-info.class,
>>>>> (compiler.misc.module.name.mismatch: mod/module-info, <error>))
>>>>>    1 error
>>>>


From matthias.baesken at sap.com  Wed Aug  9 14:26:26 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 09 Aug 2017 14:26:26 -0000
Subject: jdk9 / jdk10 : NPE in visitIdent in javac when addition of module(s)
 is missing in compilation
Message-ID: <9a38bc172f574530b44c922a9771b70b@sap.com>

Hello ,
     we noticed the issue below in jdk9/jdk10 (current builds).
See also bug  https://bugs.openjdk.java.net/browse/JDK-8186030     .
In case of missing modules , the javac compilation might run into an NPE.
One can of course work around this by adding null check, but maybe you have something "better" in mind.

This is the example program (please note that when directly importing
"import javax.rmi.PortableRemoteObject;"
we get a decent error message and not the NPE).
----------------------------- snip -------------------------------------------
import javax.rmi.*;

// this leads however to "error: package javax.rmi is not visible"
//import javax.rmi.PortableRemoteObject;

import java.io.File;
import java.rmi.RemoteException;

public class Sample extends PortableRemoteObject {

    public Sample(File file) throws RemoteException {
    }
}
-------------------------------------------------------------------------------

When adding the missing module in the compilation (--add-modules java.se.ee) all works fine and compiles.
Otherwise we get the NPE because some fields ( e.g. sym) are null and this is not handled.
9/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java

        public void visitIdent(JCIdent tree) {
            // comment added : tree.sym is null in our special missing module case of the example
            // we could add here e.g. some error generation
            //if (tree.sym == null) {
            //    ... error message ??
            //}
            if (tree.sym.kind == VAR) {
                checkInit(tree.pos(), (VarSymbol)tree.sym);
                referenced(tree.sym);
            }
        }

So  should I make a change and generate a  proper error  in  visitIdent   when  sym is null ?
Or has someone something better in mind ?


Btw I found a similar bug and  recent addition addition by Coleen Phillimore :

NPE in Flow.visitIdent
https://bugs.openjdk.java.net/browse/JDK-7194212

(Coleen Phillimore added a comment - 2017-05-23 11:24  , looks similar ).


First the working compilation :
-------------------------------------

/openjdk/nb/linuxx86_64/last_known_good/output-jdk9/images/jdk/bin/javac --add-modules java.se.ee Sample.java
Now the NPE when the module is not added (jdk9 and jdk10 show the error).
---------------------------------------------------------------------------
/openjdk/nb/linuxx86_64/last_known_good/output-jdk9/images/jdk/bin/javac Sample.java
An exception has occurred in the compiler (9.0.0.1-internal).
 Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates.
 Include your program and the following diagnostic in your report. Thank you.
java.lang.NullPointerException
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitIdent(Flow.java:2478)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2237)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:393)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1451)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanExpr(Flow.java:1707)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitApply(Flow.java:2331)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1628)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:393)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1451)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitExec(TreeScanner.java:213)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1446)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:393)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1451)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBlock(Flow.java:1956)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1014)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:393)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1451)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:1884)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:393)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1451)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:1822)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:393)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1451)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:2521)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:2504)
                at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:212)
                at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1389)
                at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1363)
                at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:959)
                at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:302)
                at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:162)
                at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
                at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)


/openjdk/nb/linuxx86_64/last_known_good/output-jdk10/images/jdk/bin/javac Sample.java
An exception has occurred in the compiler (10.0.0.1-internal).
Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates.
Include your program and the following diagnostic in your report. Thank you.
java.lang.NullPointerException
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitIdent(Flow.java:2477)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2237)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:395)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1450)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanExpr(Flow.java:1706)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitApply(Flow.java:2330)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1628)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:395)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1450)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitExec(TreeScanner.java:213)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1446)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:395)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1450)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBlock(Flow.java:1955)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1014)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:395)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1450)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:1883)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:395)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1450)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:1821)
                at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774)
                at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:395)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1450)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:2520)
                at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:2503)
                at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:214)
                at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1392)
                at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1366)
                at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:964)
                at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:305)
                at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165)
                at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
                at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)


Thanks, Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170809/f5d4a0f7/attachment-0001.html>