Community
Participate
Working Groups
The workspace preferences allow flagging discouraged and forbidden references as errors, but there is no mechanism to do this with the batch compiler. Specifically, PDE/Build would like to pass an option through the ant adapter specifying that these be reported as errors. One suggestion is a command line: -error:discouraged,forbidden The generalization of this is to allow any of the warnings to be turned into errors. (I had thought there was already a bug on this, but I couldn't find it).
Sounds fair, yet, how should combinations with -warn be evaluated? think of -warn:-discouraged -error:+discouraged -warn:none -error:+discouraged -warn:+discouraged -error:none etc. Would you simply expect "error" to take precedence? Should the general "none" allow exceptions? Mh... might not be obvious in all cases.. It might actually be more transparent to expose the three valued logic at this interface, too. An ugly but consistent variant could be -warn:+discouraged,!forbidden meaning: treat disouraged as WARNING treat forbidden as ERROR ?
I realize it is important to get the details right for how users specify what to treat as errors, and to specify a reasonable behavior for all possible input options. But please don't let the difficulty of specifying the behavior of the edge cases stop you from implementing the basics. Personally, I don't really care what happens when a user specifies "-warn:-forbidden -error:+forbidden". I just want there to be a reasonable way to specify that forbidden messages be an error rather than a warning. To keep the discussion going, I'll throw out my preference, even though it's not a strong opinion: -warn:none -- disable all warnings -warn:errors -- treat all enabled warnings as errors -warn:<warnings> -- enable exactly the listed warnings -warn:+<warnings> -- enable additional warnings -warn:-<warnings> -- disable specific warnings -warn:#<warnings> -- treat listed warnings as errors (This makes the three-valued logic visible through the -warn option. I like '#' rather than '!' to indicate errors, but again that's not a strong preference.)
I'll implement this using -errors:.... The precedence rule is simple. The last one on the command line wins. I don't like too much the idea of reusing -warn to convert some keys to errors instead of warnings. -warn:... should be reserved for warnings only.
Since there is no default errors reported, I don't think we should use '-' or '+' for errors. We should expect one option "-errors:....." on the command line that specifies the list of warning token that should be converted to errors regardless of the fact that the corresponding warning is enabled or not. If you have any thoughts on this, please let me know.
Discussing with Andrew, he wants to keep '+' and '-' for errors to be able to add more or remove errors for different bundles when the overall build sets it own errors level. I'll preserve the fact that without '+' and '-', the last errors option will override all previous ones. This is what we do right now for warnings.
Created attachment 148908 [details] Proposed fix Andrew, please let me know if this meets your needs.
I still need to handle the allJavadoc and javadoc warning tokens. Also the tasks defined inside the warnings have to be handled.
For tasks setup, do we want the ability to set different severity for different task? For example: -error:tasks(FIXME) -warn:tasks(TODO) FIXME would be reported as an error whereas TODO would be a warning only. I need to add more support if we want to do this.
I cannot change the way tasks are handled. -error:tasks(FIXME) -warn:tasks(TODO) would report all tasks as warnings. -warn:tasks(TODO) -error:tasks(FIXME) would report all tasks as errors. I cannot change that without breaking existing users. The tasks names are not stored with their corresponding severity. So I'll put this in place, but I would discourage such usage of tasks.
Created attachment 148925 [details] Proposed fix + regression tests + fix typo in field name
Created attachment 148927 [details] Proposed fix + regression tests Forgot to set tasks as warnings by default to match existing default behavior.
Released for 3.6M3. Regression tests added in: org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest#test293 org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest#test294 org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest#test295
I did a quick test and the patch seems to work for me. I raised bug 291527 to allow setting these options in build.properties for headless build.
Looks good. Some minor thing: -err would better fit to -warn (like warning vs. error). jdt_api_compile.htm seems not to be updated yet.
Changed -error: to -err: I'll update the documentation as part of the fix for bug 291579.
Verified for 3.6M3 with build I20091013-1302
Correction : The build used for verification is I20091026-0800
*** Bug 168604 has been marked as a duplicate of this bug. ***
