Community
Participate
Working Groups
Using HEAD from master and the following test case, you can see that the foo method is compiled as a problem method when no error is reported to the user. So this makes it impossible for the user to find out when problem methods are generated and this can cause issues at runtime. Add this test inside org.eclipse.jdt.core.tests.compiler.regression.NonFatalErrorTest: public void test007() { if (this.complianceLevel < ClassFileConstants.JDK1_5) { return; } Map customOptions = getCompilerOptions(); customOptions.put(CompilerOptions.OPTION_FatalOptionalError, CompilerOptions.ENABLED); customOptions.put(CompilerOptions.OPTION_ReportUnusedLocal, CompilerOptions.ERROR); customOptions.put(CompilerOptions.OPTION_SuppressWarnings, CompilerOptions.ENABLED); customOptions.put(CompilerOptions.OPTION_SuppressOptionalErrors, CompilerOptions.ENABLED); customOptions.put(CompilerOptions.OPTION_ReportUnusedWarningToken, CompilerOptions.ERROR); runConformTest( new String[] { /* test files */ "X.java", "public class X {\n" + " @SuppressWarnings(\"unused\")\n" + " static void foo() {\n" + " String s = null;\n" + " System.out.println(\"SUCCESS\");\n" + " }\n" + " public static void main(String argv[]) {\n" + " foo();\n" + " }\n" + "}" }, "SUCCESS" /* expected output string */, null /* no class libraries */, true, null, customOptions /* custom options */, // compiler results null /* do not check error string */); } and run it. I think this should pass. Right now the filtering of problem for compilation unit regarding @SuppressWarnings is done after the code generation is complete. I think we should do it for each problem when the problem is being reported in a situation where optional error is treated as fatal, because the fatal nature aborts the current code generation. Right now the only workaround is to disable the option to treat optional errors as fatal. We should never generate a problem method when the corresponding error is not reported to the user.
I'll take a look.
Ayush, please follow up for M5. bug 365437 comment#6 includes patch for that bug and this bug.
This is same as bug 346175. The patch for this in bug 365437 comment#6 is similar to the changes in bug 346175 comment#26. I think it is better to separate the issues in the patch of bug 365437 comment#6. I will look at both the patches and go with the better patch.
Marking this as a duplicate as bug 346175 has more discussions. *** This bug has been marked as a duplicate of bug 346175 ***
Verified for 3.8M5 using build I20120123-1800