Community
Participate
Working Groups
3.2M4 there should be a warning on unused @SuppressWarnings annotations (just like we have one on 'unused exceptions') for example here the annotation is unused - it just pollutes code: If it was for a whole class if would've been even worse @SuppressWarnings("unchecked") //unused void doNoEvil(){ System.out.println("hello world"); }
Agreed. It may be too late for 3.2, as require some preference addition, which is API (and we almost reached API freeze).
A question arises though: can you disable an "unused annotation" warning with an additional @SuppressWarnings("unused") annotation? My intuition is to "just say no".
Good suggestion. Need to consider unhandled warning tokens as well (likely ignore them, since there is already a diagnosis for spotting them).
*** Bug 161564 has been marked as a duplicate of this bug. ***
Reopen to assign to Olivier.
Just to make sure it wouldn't get lost, it should also warn about an unused @SuppressWarnings("unused"), such as this: public int foo(@SuppressWarnings("unused") int x) { return x; }
re comment 6. Agreed that it should be able to detect that. But see my comment 2 - should you be able to do the following (i think not, because then it's "turtles all the way down", i.e., you'd be able to supress supressions of supressions etc)? @SuppressWarnings("unused suppression") public int foo(@SuppressWarnings("unused") int x) { return x+1; }
I don't think @SuppressWarnings("unused") should make warnings about unused suppressions disappear. So in this example: @SuppressWarnings("unused") public int foo(@SuppressWarnings("unused") int x) { return x; } The second @SuppressWarnings is clearly unused, and should be warned about, because the first @SuppressWarnings should not apply to unused suppressions. In return, because the first suppression is therefore unused itself, it should be warned about, too.
Yes, definitely @SuppressWarnings shouldn't be able to silence warnings related to itself (being unused).
Created attachment 81311 [details] Proposed patch
Created attachment 81320 [details] Better patch
Added new compiler optional warning for diagnosing unnecessary @SuppressWarnings annotation. This is mostly helpful to get rid of @SupressWarnings(...) annotations which were necessary a while ago, but are no longer useful. Note that @SuppressWarnings("all") is still silencing the warning for unnecessary @SuppressWarnings, as it is the master switch to silence ALL warnings. Also added option: JavaCore.COMPILER_PB_UNUSED_WARNING_TOKEN and problem ID IProblem.UnusedWarningToken. * COMPILER / Reporting Unnecessary @SuppressWarnings * When enabled, the compiler will issue an error or a warning when encountering @SuppressWarnings annotation * for which no corresponding warning got detected in the code. This diagnostic is provided to help developers to get * rid of transient @SuppressWarnings no longer needed. Note that @SuppressWarnings("all") is still * silencing the warning for unnecessary @SuppressWarnings, as it is the master switch to silence ALL warnings. * - option id: "org.eclipse.jdt.core.compiler.problem.unusedWarningToken" * - possible values: { "error", "warning", "ignore" } * - default: "warning"
Released for 3.4M3 Fixed
*** Bug 207746 has been marked as a duplicate of this bug. ***
I wonder if the option should not have been named used the 'unnecessary' token instead of the 'unused' token. If you consider unnecessary semi-column and others, option names and error messages are more aligned than in the present case. Note also that no other error reporting option documentation takes any care of insisting that SuppressWarnings("all") works as expected for it... We may want to consider stripping this from the option documentation. Philippe, what do you think?
Unused --> unnecessary, sounds fine to me. We do have unused ones as well... (only need to sync with JDT/UI since they may have stolen the value already) Martin : can you tell ? Re: insisting on @SuppressWarnings("all"), I would keep it, since it is very related to @SuppressWarnings anyway, and is an interesting question to decide whether this warning can itself get silenced or not... I would not mind upgrading all descriptions of optional problems to indicate which warning token can be used to silence them (if any).
Discussing this further, it occurs that Philippe and Martin are reasonably happy with the current situation, and that there is no absolute need to change anything. Verified for 3.4M3 using I20071029-0010 build.
