problem with all type annotations on method parameters

[Werner Dietl]

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