redundant cast test LintCast.java failing

[Werner Dietl]

Steve, Jon, all,

I think the current output in type-annotations LintCast.out is correct.
The previous output contained type annotations in the error messages,
which I don't think were expected. Also, the type annotations were not
consistently included - for some errors they showed up, but not for all.

However, the type-annotations test passes for me - I've changed the impl
and the expected output and get consistent results.

Jon, I agree that a pure refactoring shouldn't require changes in test
cases. However, I do think this change is desired. We should double
check which behavior seems more desirable and then fix the output for
the test case.

Steve, can you give more details about which version is failing? I can't
reproduce it in type-annotations.

cu, WMD.


On 09/23/2013 12:21 PM, Jonathan Gibbons wrote:
> On 09/23/2013 12:14 PM, Steve Sides wrote:
>> Hi Werner,
>> I also noticed a recent change removed an '@A' from the expected
>> output of the test
>> test/tools/javac/annotations/typeAnnotation/failures/LintCast.java
>> and the test now fails.
>>
>> The test case in LintCast.java is
>>
>>     void array() {
>>         int @A [] a = null;
>>         int[] a1 = (int[])a;     //this line is the one in question
>>         int[] a2 = (int @A [])a;
>>     }
>>
>> This casts 'int @A[]'a  to 'int[]'.  The expected was changed to:
>>
>>  LintCast.java:27:20: compiler.warn.redundant.cast: int[]
>>
>> which removed the @A.  The warning text is more explicit than the
>> diagnostic key and states,
>>
>> Xlint:cast Test.java
>> Test.java:13: warning: [cast] redundant cast to int @A []
>>         int[] a1 = (int[])a;
>>                    ^
>> 1 warning
>>
>> Was the change to the out file expected? I makes more sense, but was
>> it expected?
>>
>> -steve
> 
> Steve,
> 
> Thanks for the detail you provide here.
> 
> I raised this issue with Werner in my review of a recent changeset last
> week.
> 
> Looking at the details you provide, it does seem that the change is
> correct: after all, there is no annotation on the statement in question,
> and so it seems like it was an error that it appears in the diagnostic.
> 
> -- jon
> 
>