Ability to print both human-readable message and @SuppressWarnings value for each violation

[GoogleCodeExporter]

Normally, the framework outputs a human-readable error message for each 
violation and it's not clear what needs to be passed into @SuppressWarnings to 
suppress it. -Anomsgtext prints the @SuppressWarnings value but then it's hard 
to understand what the error means.

We need an option that causes the framework to output *both* pieces of 
information such as:

C:\Users\Gili\Documents\vtlr\database\src\main\java\com\vtlr\web\database\trigge
r\constant\EnforceConstants.java:[43,11]
Reason: the constructor does not initialize fields: columnPrefix
@SuppressWarnings value: "nullness:fields.uninitialized"

Original issue reported on code.google.com by cow...@bbs.darktech.org on 25 Nov 2013 at 5:37

[GoogleCodeExporter]

I agree that this is a desirable feature -- it's something that has sometimes 
annoyed me too.

I suggest that the format should be the same as the one javac currently uses:  
put the warning key on the same line as the warning/error message itself, at 
the beginning of the line in square brackets.

For example, javac currently outputs

  warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding method is missing '...' 

and the Checker Framework should adopt the same format for consistency.

Original comment by michael.ernst@gmail.com on 25 Nov 2013 at 1:42

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

There are two kinds of keys that can be used to suppress a warning using 
@SuppressWarnings: either one of the values returned by 
checkers.source.SourceChecker.getSuppressWarningsKeys() or the particular error 
key (or both separated by a colon, as shown by cowwoc).

Should we output both pieces of information or just the particular error key?

Complex systems like the Nullness Checker do support a list of possible 
suppression keys. Should all of them be listed, e.g. as:

WhileTest.java:21: error: [[initialization, abstractnullnessfbc, fbc, 
nullness]:assignment.type.incompatible] incompatible types in assignment.
        nnz = z;

or just one? (But which one? There is currently no requirement on the ordering 
of suppression keys.)

For systems that only have a single suppression key, should we be consistent, 
and use:

UsesObjectEqualsTest.java:23: error: [[interning]:superclass.unmarked] 
superclass must be @UsesObjectEquals
    @UsesObjectEquals class E extends D {}

or simplify the output to:

UsesObjectEqualsTest.java:23: error: [interning:superclass.unmarked] superclass 
must be @UsesObjectEquals
    @UsesObjectEquals class E extends D {}

We could by default only show the specific error key and add an option to also 
show all suppression keys; e.g. by default we would get:

WhileTest.java:21: error: [assignment.type.incompatible] incompatible types in 
assignment.
        nnz = z;

and with an option (how should we name this?), we would get:

WhileTest.java:21: error: [[initialization, abstractnullnessfbc, fbc, 
nullness]:assignment.type.incompatible] incompatible types in assignment.
        nnz = z;

Thoughts?

Original comment by wdi...@gmail.com on 8 Jan 2014 at 4:39

[GoogleCodeExporter]

I like the idea of showing [assignment.type.incompatible] by default and adding 
an option (say -listallsuppressionkeys) that displays all possible keys.

Original comment by cow...@bbs.darktech.org on 8 Jan 2014 at 4:53

[GoogleCodeExporter]

This feature has been implemented.
By default, we show the most specific error message.
Use -AshowSuppressWarningKeys to show additional suppression keys that can be 
used.

Original comment by wdi...@gmail.com on 7 Feb 2014 at 10:02

• Changed state: Pushed

[GoogleCodeExporter]

Original comment by Jonathan...@gmail.com on 20 Feb 2014 at 6:41

• Changed state: Fixed