Community
Participate
Working Groups
Build ID: 3.2.0 Steps To Reproduce: Typically, developers will ignore warnings that don't stop the build from working. We'd like to be more strict, and treat all warnings as errors. More information: Could be done as a cmd line option to the compiler. (We use the compiler through Ant, but it's easy enough to pass cmd line params to the compiler). Something like: -warningsAsErrors
What about -error:+unused,... instead ? This would allow you to specify some errors and warnings independently from each other.
Created attachment 82453 [details] Exploratory Discussed the case with Philippe today and we agreed that: - the current code for -warn may diverge from what we want; - we need more test cases in that area; - we would expect -warn to abide to the following rules: - multiple -warn behave exactly as if they were concatenated (aka '-warn:xxxx -warn:yyyy' is exactly the same as '-warn:xxxx,yyyy', for all possible values of xxxx and yyyy); - last token wins; - macros behave properly (including implicit macros like allDeprecation); - the existing documentation and code disagree (may need to enter dedicated bugs for that); - we should align -error on (fixed) -warn as far as this can be; - some cases are known to need a twist (aka tasks: we have no support for 'error priority tasks' for now - simplest move is to avoid -error:tasks() altogether). THE ATTACHED PATCH PRECEDES the said discussion, and would need work to align with the objectives defined above.
Thinking more about it, I dislike the concatenation rule. Current doc says that '-warn:null' sets the warnings to exactly null. Which implies '<whatever> -warn:null' sets the warnings to exactly null. Assuming we adopted the concatenation rule, '-warn:none -warn:+deprecation -warn:null' would equate '-warn:none,+deprecation,null', that would mean null. But '-warn:none -warn:+deprecation,null', which means deprecation+null, would also equate '-warn:none,+deprecation,null'. We would then have two conflicting interpretations of a single canonical form: null or deprecation+null. I have been tempted to consider that the very first instance of non-signed token would keep the property of erasing before setting. But this does not fly well: -warn:+deprecation -warn:null -warn:unused would be null+unused, and equivalent to -warn:+deprecation,null,unused. But then, the current meaning of the latter form is all defaults + deprecation + unused, for which the new notation would (recursively) require a full adornment like -warn:+deprecation,+null,+unused. Note also that a very remote -warn:full near the start of the command line would impair the erasing power of a -warn:unused close to the end of the command line, and that this notion of 'first instance' would compell to use explicit -warn:none to make a late decision about an exact set of warnings. Unless a simple doc is exhibited that cleanly accounts for these behaviors, I would vote for the currently documented behavior, slightly augmented to account for the current (code to be verified) behavior of combined pluses and minuses, for which I believe -warn:+x,y,z,-t,u,v equates -warn:+x,y,z -warn:-t,u,v that in turn equates -warn:+x -warn:+y -warn:+z -warn:-t -warn:-u -warn:-v, and which specified behavior does not depend on former -warn directives (the result does, not the behavior). I would in particular strictly enforce that <whatever> -warn:x means exactly x, which implies that -warn:x -warn:y means y, while -warn:x,y or -warn:x -warn:+y mean x,y.
Opened a few bugs to report the strangest cases, that I added to the dependencies for this bug. Note that active tests admit the following, non-documented equivalence: -warn:+x,y -warn:-z,w == -warn:+x,y,-z,w It has no side effect I could think of, and is reasonably intuitive given the doc (that only specifies the left-hand expression), so I'd support our keeping it unchanged.
This has been done for 3.6 with the addition of -err:.... similar to the -warn:... option as part of the fix for bug 280784. *** This bug has been marked as a duplicate of bug 280784 ***
