ElementType.TYPE_USE for a type parameter

[Alex Buckley]

Hi Steve,

The source you wrote below is completely valid.

@Uv on the class declaration of Test1 correctly produces a 
RuntimeVisibleAnnotations attribute on the class.

@Uv on the type parameter declaration of g should produce a 
RuntimeVisibleTypeAnnotations attribute on the method.

(A type parameter annotation on a generic type or method is technically 
on a declaration, and so "ought" to get RuntimeVisibleAnnotations, but 
this is impractical, so in fact it gets RuntimeVisibleTypeAnnotations.)

There must a bug in the treatment of TYPE_USE annotations on type 
parameters. It fails in a generic class declaration too: "class 
Test1<@Uv X> ...". But @Uv does work as a pure use-site annotation: 
"class Test1<X extends @Uv String> { @Uv int f; }"

Summary: a TYPE_USE annotation works in TYPE and "use" locations, but 
not TYPE_PARAMETER locations.

Alex

On 12/10/2012 1:11 PM, Steve Sides wrote:
> Hi,
>
> I starting writing some tests mixing a combination of ElementType
> targets and ran into some questions.
> Section 2.3 says,
>
> "A type annotation (one meta-annotated with
> @Target(ElementType.TYPE_USE)) is permitted to be written anywhere
> @Target(ElementType.TYPE) or @Target(ElementType.TYPE_PARAMETER) would
> permit — that is, on a class, interface, or enum declaration, or on a
> type parameter declaration."
>
> Should this mean that an annotations such as
> @Retention(RUNTIME)
> @Target(ElementType.TYPE_USE)
> @interface Uv {}
>
> should be able to be used as
>
> @Uv public class Test1 {
> <@Uv T> String g(T t) { return null; }
> }
>
> In the case of the first usage, it appears as RuntimeVisibleAnnotations
> and not RuntimeVisibleTypeAnnotations.
> The second is not accepted by the compiler.
>
> Are both these current behaviors expected? Am I reading that correctly?
>
> thanks,
> steve
>
>
>> which made the AST nicer, because we no longer need the onRightType
>> hackery.
>> I renamed the constants and updated the tests in
>>
>> langtools/test/tools/javac/annotations/typeAnnotations/referenceinfos/
>>
>> to the new location format. It's a pain to write these byte arrays by
>> hand, but I didn't see a quick way to update the testing
>> infrastructure.
>>
>> Please have a look at the tests and the code and let me know whether
>> you see any problems.
>>
>> I will next:
>> - fix inner type numbering
>> - fix JavaDoc/Symbol issue
>> - look at exception and lambda storage (I added constants and some
>> groundwork; for lambda i really need a spec to know what has to be
>> stored.)
>> - the few small other things from previous mail
>>
>> cu, WMD.
>>
>>
>> On Wed, Dec 5, 2012 at 6:03 PM, Jonathan Gibbons
>> <jonathan.gibbons at oracle.com>  wrote:
>>> On 12/03/2012 01:15 AM, Werner Dietl wrote:
>>>> Please find a patch against the type-annotations/langtools repository
>>>> attached (I just pushed a recent merge with tl).
>>>> I implemented many of the recently discussed bytecode changes: reorder
>>>> elements, remove _COMPONENT TargetTypes, and introduce TypePathEntry.
>>>> It's not quite done yet: I still need to separate numbering of type
>>>> arguments and arrays/inner types, renumber inner types, and adapt the
>>>> referenceinfo test cases (which will be a big pain and I would prefer
>>>> doing this only once).
>>>>
>>>> I would appreciate feedback on the changes to class
>>>> com.sun.tools.javac.code.TypeAnnotationPosition, in particular how I
>>>> added TypePathEntry, TPEKind, and the new location field.
>>>> The whole com.sun.tools.javac package hierarchy compiles; packages
>>>> classfile and javap currently won't compile, as they depend on code
>>>> duplicated from TypeAnnotationPosition and I only want to copy that
>>>> code over once. The uses are however mostly adapted already.
>>>>
>>>> All comments very welcome!
>>>> cu, WMD.
>>>>
>>> Generally, code looks good, except for the //TODO's.
>>>
>>> -- Jon
>>>
>>>
>>>
>>>
>>
>>
>