Type annotations on scoping mechanisms and type/declaration annotation errors

[Alex Buckley]

On 10/7/2013 7:35 PM, Werner Dietl wrote:
> Hi Alex,
>
>> 1. CantAnnotateStaticClass is still OK and CantAnnotateStaticClass2 still
>> makes me confused. Please see my question to you on
>> type-annotations-spec-observers, after your response to Srikanth on Y.YY.Z.
>
> Just replied.
> I agree that the test case CASC2 is not the cleanest and would
> appreciate somebody else independently testing the logic I
> implemented.

CantAnnotateStaticClass2.java and CantAnnotateStaticClass3.java would be 
clearer if each error line had only one annotation. For example, "@TB 
Outer . Inner" is enough to show the error - there's no need for "@TB 
Outer . @TC Inner".

What's missing are cases of the form "Top . @TB Outer . ..." - no 
annotation on Top. Currently, Top is always annotated and that's always 
an error (since Outer is not an inner class) but it means no information 
is gained from the many "@TA Top . ..." examples.

>> 2. CantAnnotateScoping.java looks good. FYI the @DA in "java. at DA
>> lang.Object" is illegal because @DA is decorating part of a type in a type
>> context, but DA is not applicable to type contexts.
>
> Do you agree with the error messages I raise in these examples?
> I also have a "java. at DA XXX.Object" test case and am not quite sure
> how many error messages would be most helpful.
> See the following test case:
>
> langtools/test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java
>
> fields f5 and f6.

Just one error message is preferable - because @DA applies to part of a 
type in a type context, but DA is not applicable to type contexts. 
'lang' should not be classified as a strict TypeName - I presume the 
presence of @DA is doing so, but it should not be revealed in an error 
message.

Alex