problem with all type annotations on method parameters

[Jonathan Gibbons]

javac is not a queue-based life form. Generally speaking,
we need to overhaul (rewrite) the increasing complex
code for analyzing annotations, and replace the series
of queues by a more lazy completion-like mechanism,
as seen in the rest of javac.

But, for now, we probably have to live with these queues.

How much do you need to determine annotation positions early?
It seems to me that early on (i.e. MemberEnter) we need to
differentiate between decl annotations and type annotations,
but that determining positions for use in the .class file can be
done a whole lot later.

-- Jon

On 01/07/2013 12:28 AM, Werner Dietl 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.
>>>
>
>