Hi George, On Sun, 1 Aug 2010, George Neuner wrote:
> I don't know if these are bugs or misunderstandings: I investigated this some over the weekend and went ahead and started a thread at: http://lists.gnu.org/archive/html/bison-patches/2010-08/msg00000.html > On page 114 of the PDF manual it says that the command line option > "--warnings=error" or "-Werror" should force bison to treat warnings as > errors. I interpret that to mean that, if a warning is generated, bison > should exit with a non-zero (fail) return code - just as it does if a fatal > problem prevents the parser from being generated. Right. > This does not work as I > expect - the return code is always zero if the parser can be generated. -Werror does turn a few warnings into errors with a non-zero return code, but those warnings are not as common as the warnings you've encountered. > Also on page 114, the manual says "--warnings=none" or "-Wnone" should > suppress all warnings. This does not work. Grammar warnings, if any, are > generated regardless of this setting. Thanks for mentioning that. I hadn't noticed it before, and I agree it is confusing. I think the idea was that -Wnone (or --warnings=none) simply disables all warnings that can be enabled by the other -W options. It's not clear to me if the documentation or the behavior needs to be fixed here. > These situations can be reproduced using any grammar with a R/R conflict or an > unexpected S/R conflict. As you'll see in the other thread, bison hasn't previously labeled the count of conflicts as a warning. Given that it's a diagnostic printed on stderr, we're now considering whether it should be labeled as a warning and thus affected by -Werror. > I believe mismatched (too many or not enough > expected) S/R warnings also should fail if "warnings=error" is selected. By "mismatched", are you referring to the case where either %expect or %expect-rr is specified? In that case, an incorrect number of conflicts produces an error not a warning, so -Werror becomes irrelevant. Our manual unfortunately uses the word "warn" in at least one context, so that needs to be fixed. > I don't mind if the parser is generated for the "--warnings=error" case ... > but the result code should indicate the condition. I've only ever seen '0' > and '1' as result codes ... perhaps a new code value should be introduced to > mean success but with warnings. The norm is for warnings to produce a 0 result unless -Werror is in effect. Bison probably shouldn't change this practice as it could cause make files to fail unexpectedly. > Hope this helps, Yes. Thanks for the report.
