problem with all type annotations on method parameters

[Jonathan Gibbons]

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.
>