javac crash for annotation on lambda formal parameter type

[Alex Buckley]

Thanks Werner. I'm cc'ing Leonid to comment about JCK coverage of 
annotations in lambda expressions.

It's wrong to lose the annotation on the header of the lambda 
expression. Instance variable initializers (and the bodies of any 
instance initializers) are necessarily compiled as if in some method, 
usually <init>, so that's where I'd expect a 
RuntimeVisibleTypeAnnotations attribute for annotations in expressions 
of instance variable initializers and instance initializers. That's what 
happens if @TA appears on the type in a 'new' expression in an instance 
variable initializer:

--
import java.lang.annotation.*;
import java.util.function.*;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE_USE)
@interface TA { };

class FieldAssignment {
   IntUnaryOperator x = new @TA IntUnaryOperator() {
     public int applyAsInt(int y) { return y+1; }
   };
}
--

Alex

On 12/5/2013 5:51 PM, Werner Dietl wrote:
> It looks like nobody ever tested Type Annotations on Lambdas in fields.
> test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java
> test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java
> contain several lambda tests, but all within methods.
>
> The code that creates the NPE tries to find the owner for a parameter symbol.
> The expectation was that a parameter is always within an method. That
> is not true for lambdas it seems.
> Even for lambdas within a method it is not modifying the correct type:
> it modifies the enclosing method's signature instead of modifying the
> lambda's signature.
>
> As lambdas do not have an ExecutableType, the right thing is probably
> to not modify the enclosing type.
> However, I didn't see a way to determine from a parameter symbol
> whether it is a lambda parameter or a normal method parameter.
>
> Also, are the expected outputs for the referenceinfos/Lambda.java test correct?
> For a lambda within a field, the type annotation is currently lost.
> Where should it show up? On the field? In the instance initializer?
>
> I pushed a changeset to type-annotations with an ugly fix for the NPE
> and the expanded test cases:
>
> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/3705299024dc
>
> cu, WMD.
>
>
>
> On Thu, Dec 5, 2013 at 7:47 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>> Starting at JDK8 b91, and continuing through b118, this innocuous program
>> crashes javac:
>>
>> --
>> import java.lang.annotation.*;
>> import java.util.function.*;
>>
>> @Retention(RetentionPolicy.RUNTIME)
>> @Target(ElementType.TYPE_USE)
>> @interface TA {}
>>
>> class LambdaFormal {
>>    IntUnaryOperator x = (@TA int y) -> 1;
>> }
>> --
>>
>> with:
>>
>> java.lang.NullPointerException
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.separateAnnotationsKinds(TypeAnnotations.java:302)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.visitLambda(TypeAnnotations.java:1080)
>>          at com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1607)
>>          at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>> ...
>>
>> This is weird because I'm sure I've annotated lambda formals in this fashion
>> since b90. It's due to TYPE_USE - if TA's target is PARAMETER, then the
>> program rightly compiles, while if TA's target is FIELD, you get the
>> expected applicability error.
>>
>> Before I file a P2 bug for this, can anyone add some color to the situation?
>>
>> Alex
>>
>> P.S. With a TA target of TYPE_USE, b90 produces a class file without the
>> expected RuntimeVisibleTypeAnnotations attribute for @TA. But that's less of
>> a concern right now.
>>
>
>
>