RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute

[Srikanth]

I am looking into this one - turns out I had a patch for this that was 
put through internal review process and some open issues that needed 
addressing caused it to be deferred.

Comparing the patches I see some common code: Eliminating the three 
calls to setTypeAttributes is
the right thing to do.

Differences come in the following form:

(1) Your proposed patch simply switches on the kind to determine whether 
annotations need to be carried over. This looks incorrect/insufficient. 
Type annotations and declarations annotations have different rules to be 
carried over.

>From 
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009865.html:

     - Declaration annotations on a lambda formal should not make it to the
        class file at all.

      - Type annotations on the type of a lambda formal should be carried
over to the type
        of the formal parameter of the synthetic method that implements
the lambda[*]

I don't think this is handled by your patch ???

(2) From https://bugs.openjdk.java.net/browse/JDK-8144185:

Not only is the range incorrect, but also LVT index appears incorrect:

I don't think this is handled by your patch ???

FWIW, JDK-8144185 carries a fix version of tbd_major and I was going to 
work on it for JDK10.
I can rework my patch and take it to push in the coming couple of weeks. 
Does that sound good ?

Thanks!
Srikanth.





On Friday 05 May 2017 05:48 AM, Srikanth wrote:
> Thanks Liam,
>
> I will take a look at this next week.
>
> Thanks!
> Srikanth
>
> On Thursday 04 May 2017 09:32 PM, Liam Miller-Cushon wrote:
>> Hello, could I get feedback on this potential fix for JDK-8144185?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8144185
>> webrev: http://cr.openjdk.java.net/~cushon/8144185/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ecushon/8144185/webrev.00/>
>>
>> We ran into this because the incorrect localvar_target crashes ASM. 
>> The change causes annotations on captured outer locals to not be 
>> propagated to the synthetic formal parameter, as discussed here: 
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html. 
>>
>>
>> I gave the parameters for captured enclosing instances the same 
>> treatment, although I'm not sure it's possible for type annotations 
>> to be attached to them.
>>
>> I also removed some calls to `setTypeAttributes` that as far as I can 
>> tell were redundant with the call to that method 
>> in `translate(Symbol, LambdaSymbolKind)`, and which were incorrect 
>> for captured outer locals.
>

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