[Checkers] Compiler annotations output
Mahmood Ali
mahmood at MIT.EDU
Wed Jul 2 01:45:22 EDT 2008
> I believe that they are still to-do items for the JSR 308 compiler
> implementation, so that the annotations appear in the class file.
> Is that
> correct?
All annotations now appear in the class file. I am not quite sure if
it is adherent to the JSR308 classfile specification.
The challenging part for me now is figuring out which type each
annotation is targeting. Annotations are associated with
TypeAnnotations that contain Position, and each Position stores the
following fields:
> TargetType type = TargetType.UNKNOWN;
>
> // For generic/array types.
> List<Integer> location = List.nil();
>
> // Tree position.
> public int pos = -1;
>
> // For typecasts, type tests, new (and locals, as start_pc).
> public int offset = -1;
>
> // For locals.
> public int length = -1;
> public int index = -1;
>
> public int bound = -1;
> public int parameter = -1;
Currently, I don't think those values get set properly. For the
following declaration for example:
@interface A {}
@interface B {}
class Test extends @A Date implements @B RandomAccess { }
Both annotations get written to the classfile, however their pos and
offsets are the same. The compiler outputs the following debugging
output:
writing @A at [CLASS_EXTENDS @-1 offset -1]
writing @B at [CLASS_EXTENDS @-1 offset -1]
I cannot see how to differentiate between them. I am afraid that I
need to delve into the compiler more. Unless there is something I am
missing.
Also, I identified the problem with the reason for ClassWriter not to
notice some of the annotations. Processing annotations is (more used
to before my change) divided between the following:
- Parser: parsing the annotations
- Attr: In the attribution phase, attributing the annotation trees.
i.e. enriching the annotation trees with their symbol and type
information.
- Desugering (TransType): Calculates the position for each annotation
- Code Generation (Gen): Lifts the type annotations to the most
enclosing symbol: field, method, or class tree; as annotations would
be attached to those symbols in the classfile. -- I moved this
functionality to desugering stage
- ClassWriter: writes the annotations to the classfile.
The problem was that in the desugering stage, the compiler rewrites
tree and trim some parts of it, namely:
- annotations on the extends and implements clauses
- all type arguments for parameterized types
Basically all that remains are the annotations on raw locations in the
receiver, new class trees, and casts within method.
When we get to the Code Generation, most of the annotations are
deleted and cannot lift the annotations to the enclosing symbol. I
moved the lifting routine to the desugering stage. Now both
ClassWriter and ClassReader see the annotations, but their fields are
not set properly.
Hope that explains the situation a bit better.
Regards,
Mahmood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/mailman/private/checkers/attachments/20080702/5b7c252f/attachment.htm
More information about the checkers
mailing list