test failures

[Jonathan Gibbons]

Woohoo.  Thanks for the update.

I'll be looking at javadoc stuff tomorrow.

-- Jon

On 05/02/2013 07:23 PM, Werner Dietl wrote:
> Hi Jon, Steve,
>
> thanks for getting back on this one. Coincidentally, I had started 
> working on this earlier today.
> I just pushed my change and that test case is now passing.
>
> Steve, could you extend BasicAnnoTests.java to make sure all 
> possibilities are covered?
>
> cu, WMD.
>
>
> On Thu, May 2, 2013 at 6:39 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Yes, it looks like the ExecutableType should be updated for
>     type-annotations on all of
>
>     * return type
>     * receiver type
>     * parameter types
>     * throw types
>
>     -- Jon
>
>
>
>     On 04/25/2013 08:07 PM, Werner Dietl wrote:
>>     Jon,
>>
>>     if you look
>>     at com.sun.tools.javac.code.TypeAnnotations.TypeAnnotationPositions.separateAnnotationsKinds
>>     you'll see code like this:
>>
>>                 if (sym.getKind() == ElementKind.METHOD) {
>>     sym.type.asMethodType().restype = type;
>>                 } else {
>>                     sym.type = type;
>>                 }
>>
>>     If the symbol is a parameter, then only its type is changed, but
>>     it looks like we never change the ExecutableType.
>>     Do you agree that this might be the source of this inconsistency?
>>     It might be enough to find the method for a parameter and update
>>     its ExecutableType, right?
>>
>>     cu, WMD.
>>
>>
>>     On Thu, Apr 25, 2013 at 10:30 PM, Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com
>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>         On 04/24/2013 09:51 PM, Jonathan Gibbons wrote:
>>>         tools/javac/processing/model/type/BasicAnnoTests.java
>>
>>         This test is failing because the internal data model for type
>>         annotations within javac is inconsistent.
>>
>>         The broken test case is this one (and maybe others like it):
>>
>>>         @Test(posn=1, annoType=TA.class, expect="4")
>>>             public int m1(@TA(4) float a) throws Exception { return 0; }
>>
>>         If you look at the ExecutableElement for m1, you can navigate
>>         to the VariableElement for the parameter "a", and from there
>>         get to the type annotations on the type used for "a".  The
>>         debug output from the test confirms the existence of @TA(4)
>>         on "float".
>>
>>         But there's a second way to get to that instance of "float".
>>
>>         From the ExecutableElement, you can get an ExecutableType
>>         using Element.asType(), and from the ExecutableType, you can
>>         get the ParameterTypes using getParameterTypes(). It seems
>>         intuitively reasonable to expect that the type of the first
>>         parameter obtained in this manner should be the annotated
>>         type "@TA(4) float".  The debug output from the test
>>         indicates there are no type annotations here, and so the test
>>         fails.
>>
>>         Generally speaking, I think all the following pairs should be
>>         equivalent^[1,2] , for any ExecutableElement ee:
>>
>>         using ExecutableElement
>>         	using ExecutableType
>>         ee.getReceiverType()
>>         	ee.asType().getReceiverType()
>>         ee.getReturnType()
>>         	ee.asType().getReturnType()
>>         ee.getParameters().get(i).asType()
>>         	ee.asType().getParameterTypes().get(i)
>>         ee.getThrownTypes().get(i)
>>         	ee.asType().getThrownTypes().get(i)
>>         ee.getTypeParameters().get(i).asType()
>>         	ee.asType().getTypeParameters().get(i)
>>
>>
>>         [1] where "equivalent" means that the types and annotations
>>         on those types should match: something like a recursive
>>         evaluation of
>>                 Types.isSameType(a, b) &&
>>         Objects.equals(a.getAnnotationMirrors(),
>>         b.getAnnotationMirrors())
>>
>>         [2] In practice, I would expect the values to be ==, but I
>>         would not mandate that.
>>
>>         The BasicAnnoTests covers some of these cases, but should be
>>         extended to cover all of them.
>>
>>         -- Jon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     -- 
>>     http://www.google.com/profiles/wdietl
>
>
>
>
> -- 
> http://www.google.com/profiles/wdietl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20130502/aa54e9ab/attachment.html