RFR [JDK8]: 7153951: -Xlint:auxiliaryclass

[Jonathan Gibbons]

On 10/23/2012 11:47 AM, Fredrik Öhrström wrote:
> 23 okt 2012 kl. 20:29 skrev Jonathan Gibbons:
>>
>> Maybe so, but you are relying on unspecified behavior.  The tag spec 
>> says:
>>
>> The first token in the leading comment in the defining file of a test 
>> must be
>> "@test".  The harness discovers defining files by looking for such 
>> tokens.  A
>> file without comments is not a defining file.  A file whose leading 
>> comment
>> does not start with "@test" is not a defining file.
>>
>
> Undoubtedly a bad specification, but also a bad implementation that does
> not follow the bad specification. Oh well, will move the comment.
>
>>
>> OK, but you still have no tests that verify the correct messages are 
>> being generated.
>>
>
> I believed that this test:
> http://cr.openjdk.java.net/~ohrstrom/webrev-7153951-auxiliaryclass-v6/test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java.html 
> <http://cr.openjdk.java.net/%7Eohrstrom/webrev-7153951-auxiliaryclass-v6/test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java.html>
> does exactly that. Does it not?
>
> //Fredrik
>

The primary purpose of the diags/examples tests are to provide a simple 
example of each of the diagnostics in context, for the benefit of 
reviewers, and the localization team, to see the sort of program that 
can trigger the diagnostic.  While there is some self-consistency 
checking to ensure that the declared keys are generated, there is no 
check on the overall diagnostic, such as the file being reported, the 
position within the file, any arguments for the diagnostic, and so on. 
It is also a non-goal of the diags/examples area to provide exhaustive 
coverage of the different ways that the diagnostic may be generated.

The standard way of providing more complete test coverage for 
diagnostics is to make sure that every test that uses "@compile/fail" 
also specifies a golden file for the diagnostics. Since the golden file 
can potentially depend on external or somewhat unrelated factors like 
the absolute path of the source file, or the exact text of the error 
message, we use the -XDrawDiagnostics option to print out the salient 
details of the diagnostic, in a way that is independent of those 
external factors.

Thus, any test containing @compile/fail should use a line like
     @compile/fail/ref=Test.out -XDrawDiagnostics Test.java

adding in additional options, or changing the file names as needed.

-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20121023/2f191c8d/attachment.html