type-annotations test failures: update
jonathan.gibbons at oracle.com
Sat Apr 13 07:48:22 PDT 2013
On 04/11/2013 01:26 AM, Werner Dietl wrote:
> On Wed, Apr 10, 2013 at 6:39 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> OK, after making allowances for some pilot error earlier today, and after
>> fixing up problems with diagnostics, I've reduced the test of test failures
> thanks for your fixes and added test cases!
>> to these:
>> Failed. com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
>> Failed. com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
>> Bhavesh says the first is fixed in his webrev which he is waiting to push,
>> so I can see us overlooking these for now. (We need to break a circular
>> dependency, here.)
> Great! Could we push Bhavesh's changes into the type-annotations repo
> to test them?
Bhavesh says his fixes will arrive in TL/langtools before Monday.
He has tested his changes against type-annotations, but because
he will be puhing to TL some new test cases will fail and will
be @ignored. Once his bits arrive in TL, we should pull them down
into type-annos and remove the @ignore. We should be able to
grep for 8012173 to locate the appropriate @ignore tags.
>> Failed. tools/javac/annotations/typeAnnotations/classfile/T8008762.java
> Please see this message:
> and my exchange with Steve earlier this week. I think both issues are
> related and an answer to that email would be appreciated.
> These two are about repeated type annotations and Joel will look at them.
> Steve also disabled a few other tests related to repeated type
> annotations that we should enable eventually.
> I've been working on this one over the past several days and just pushed my fix:
> and a few earlier changesets.
> Please have a look through this change, in particular the places
> marked as "TODO" or "review".
> I think this works as desired now, but somebody should look through my
> examples and extend them with code that creates crazier exception
> Also, I changed things I didn't have to touch before - e.g. Pool - and
> somebody should review them.
> On the bright side, the Checker Framework still works with these changes.
> This is the next one on my TODO list.
> After this, I will look at the bug-report from Steve earlier this week
> about nested classes in throws.
> Finally, I'll do the method/constructor receiver cleanups suggested by
> you and check that all of Alex's descriptions are implemented.
>> I'm assuming these are serious and need to be fixed.
>> Failed. tools/javac/lambda/SerializedLambdaInInit.java
>> Error. tools/javac/lambda/TargetType24.java
>> I'm prepared to overlook these for now, although I'll also check if these
>> are also failing in tl. I don't think they are.
> I haven't looked at test cases outside of javac recently and wouldn't
> really know how I've broken those two.
> I'll have a look.
Pass on Lambda ones for now.
>> Failed. tools/javac/processing/model/type/BasicAnnoTests.java
>> I wrote this test and pushed it into type-annotations because it seemed
>> to demo a problem with the support for the javax.lang.model API.
>> Someone needs to look at it.
> I can have a quick look at this test case, I haven't seen it yet. I'll
> come back with questions.
> Is there any particular deadline for which we should aim for TL integration?
No hard deadline this time, but sooner is better than later. I would just
like to see the latest/greatest type-anno bits in TL, and I'm trying to
reduce the overall number of @ignore in TL/langtools. They're
> cu, WMD.
More information about the type-annotations-dev