problem with all type annotations on method parameters

[Werner Dietl]

Jon,

after what phase do we want the type annotation positions to be valid?

I currently separate declaration and type annotations for expression
locations at the end of Attr, which is too late for some semantic
checks that happen earlier in Attr.
I want to split up the organizeTypeAnnotations methods back into two
methods: one to separate declaration and type annotations and one to
determine type annotation positions.

After MemberEnter, I would say we just need the separation of
declaration and type annotations.
During Attr we also only need the separation.

Only once Attr is finished with a class do we set the type annotation
positions. Or should we do this even later?

Comments?

cu, WMD.

On Mon, Jan 7, 2013 at 12:28 AM, Werner Dietl <wdietl at gmail.com> wrote:
> Jon, Joel, all,
>
> I've put a patch here:
>
> homes.cs.washington.edu/~wmdietl/tmp/tas-in-memberenter.diff
>
> I have trouble with the interaction with repeating annotations and had
> to add a second, very imaginatively named, typesQ2 queue to Annotate.
> If I use the existing typesQ or the repeatedQ for this purpose in
> MemberEnter, repeating annotations don't work.
> The reason is that first we need to package up the repeating
> annotations and only afterward should we determine their positions.
> When we did this in Attr, it looks like repeating annotations were
> already packaged up.
>
> Do you see a nicer solution than introducing the typesQ2? Maybe there
> is a better place for the call in MemberEnter? What would be a better
> name instead of typesQ2?
>
> I kept TypeAnnotations simple and now have two methods:
> organizeTypeAnnotationsBodies and organizeTypeAnnotationsSignatures,
> which are called from Attr and MemberEnter, respectively.
> Does this interface look OK or should I change it to instantiate a
> TypeAnnotations object and then call a method on it?
>
> I made a few other fixes to javadoc and it looks like javadoc sees
> AnnotatedTypes. However, I don't see annotations in the HTML output.
> Do you have some modifications for javadoc to see type annotations?
>
> Best regards,
> cu, WMD.
>
>
> On Wed, Jan 2, 2013 at 8:17 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> On 01/02/2013 08:11 PM, Werner Dietl wrote:
>>>
>>> On Wed, Jan 2, 2013 at 7:44 PM, Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>> On 01/02/2013 05:56 PM, Werner Dietl wrote:
>>>>>
>>>>> I can introduce this separation again.
>>>>> There are unfortunately no test cases for the annotations in Types. Is
>>>>> there a way we could test this, independently of javadoc?
>>>>
>>>>
>>>> It's high on my list, for variety of reasons, to have a "debug printer"
>>>> for ASTs.  We could use that as the basis for a series of tests to
>>>> validate
>>>> the structure of the AST -- and semantic info like annotations -- at
>>>> various
>>>> points through the compilation pipeline.
>>>>
>>>> As for testing separately of javadoc, all we need to do is to validate
>>>> the
>>>> data
>>>> structures after Enter/MemberEnter.
>>>
>>> A standard "debug printer" way to compare this information would be
>>> great and would ensure that the information in Type is valid after
>>> various phases.
>>
>>
>> I'll work on this tomorrow.  I did something similar for the DocTree
>> API, so I can cut-n-paste the ideas.
>>
>>
>>>
>>>
>>>> It also seems to be that the problems would be visible during "regular"
>>>> annotation
>>>> processing, which occurs before Attr has been called.
>>>
>>> There is no "regular" annotation processor that looks at type annotations
>>> yet.
>>
>>
>> Yeah, I was just pointing out that if you were to write tests that
>> leveraged the anno proc framework, they would see the issues too.
>>
>>
>>> The Checker Framework runs after Attr and therefore I didn't run into
>>> any issues.
>>> I think a "debug printer" would be the preferable way to test this and
>>> I'll wait to hear from you before adding any tests.
>>
>> Agreed on debug printer.  I envisage a test strategy based on
>> test classes containing type annos in all positions, and a custom
>> tester to validate the AST for each of these classes.
>>
>>
>>>
>>> I agree with your other two points, that is, I'll see what the new
>>> interface will look like and I'll clean up all TODOs and commented
>>> code.
>>>
>>> cu, WMD.
>>>
>>
>
>
>
> --
> http://www.google.com/profiles/wdietl



-- 
http://www.google.com/profiles/wdietl