-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@SuppressWarnings("all") on generated Java classes is ineffective #186
Comments
Which java compiler are you using that is ignoring the "all" statement? Mine (oracle-jdk 1.8.0.121) is quiet fine with it: harry@harry ~$ echo -e '@SuppressWarnings("all")\npublic class Hello {\n\tpublic static void main (String [] args) {\n\t\tint a=0;\n\t}\n}' > /tmp/Hello.java && cat /tmp/Hello.java && javac /tmp/Hello.java && echo $?
@SuppressWarnings("all")
public class Hello {
public static void main (String [] args) {
int a=0;
}
}
0 |
1.8.0_92 here, but that particular example prints 0 with or without the SuppressWarnings line. Here's my example. With no suppression:
With
But it does suppress it with
|
Also tried on Java 9-ea, since that happened to be sitting around on my computer, and same result on that version. |
Yes, with the |
This makes some sense then. I guess "cast" type warnings are disabled by default. |
Ah okay, according to http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#nonstandard right, Interestingly the following is working: ~ $ echo -e '@SuppressWarnings("cast")\npublic class Hello {\n\tpublic static void main (String [] args) {\n\t\tString a = (String) "a";\n\t}\n}' > /tmp/Hello.java && cat /tmp/Hello.java && javac -Xlint:all -Werror /tmp/Hello.java && echo $?
@SuppressWarnings("cast")
public class Hello {
public static void main (String [] args) {
String a = (String) "a";
}
}
0 while this example fails: echo -e '@SuppressWarnings("all")\npublic class Hello {\n\tpublic static void main (String [] args) {\n\t\tString a = (String) "a";\n\t}\n}' > /tmp/Hello.java && cat /tmp/Hello.java && javac -Xlint:all -Werror /tmp/Hello.java && echo $?
@SuppressWarnings("all")
public class Hello {
public static void main (String [] args) {
String a = (String) "a";
}
}
/tmp/Hello.java:4: warning: [cast] redundant cast to String
String a = (String) "a";
^
error: warnings found and -Werror specified
1 error
1 warning I would consider this a bug in the javac-compiler itself but maybe I am missing something |
I think it's just that "all" is not a class of warning, and not handled specially by the compiler either, so it doesn't suppress anything. The confusing thing is that IDEs do treat it as a special value. |
According to the Java specification at http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 its up to Java implementations if "all" is a valid value. E.g., for Eclipse the suppressing string "all" is well defined - see http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-suppress_warnings.htm |
Yeah. I also remember that previous versions of either Eclipse or IDEA didn't recognise "all", but did recognise "ALL", so in some places in our code we ended up with So anyway, it seems that we'd want "all" and "cast", even though it seems counterintuitive... Or I guess the warnings could be fixed. In my case, at least, every single cast warning is about a cast to Object. |
javac apparently ignores
@SuppressWarnings("all")
. Therefore, this should be replaced by the list of actual warnings ANTLR's generated code triggers, to actually suppress the warnings.I'm not exactly aware of the complete set of warnings it can create, but here's the common ones from our build.
Missing Javadoc, basically. I can't tell what the warning category is for this one (it appears to be blank), but perhaps it could be suppressed by generating some "token" (no pun intended) Javadoc.
This one is a bit more perplexing. You can suppress these with
SuppressWarnings("cast")
. But I get 250 of these "cast" warnings, and it's always toObject
. If it's always toObject
, why even cast? i.e., for this one, maybe ANTLR could just generate better code.The text was updated successfully, but these errors were encountered: