| Message ID | CAESRpQBi5c6KCnyB3iR7OR_xHxsoe0tie2d-bP3xjuX6y273dg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Fri, 17 Oct 2014, Manuel López-Ibáñez wrote: > +Some options, such as @option{-Wall} and @option{-Wextra}, turn on other > +options, such as @option{-Wunused}, which may turn on further options, > +such as @option{-Wunused-value}. The combined effect of positive and > +negative forms is that more specific options have priority over less > +specific ones, independently of their position in the command-line. For > +options of the same specificity, the last one takes effect. Options > +enabled or disabled via pragmas (@pxref{Diagnostic Pragmas}) take effect > +as if they appeared at the end of the command-line. This part is OK. > @@ -3318,8 +3327,8 @@ > > @item -pedantic-errors > @opindex pedantic-errors > -Like @option{-Wpedantic}, except that errors are produced rather than > -warnings. > +This is equivalent to @option{-Werror=pedantic} plus making into errors > +a few warnings that are not controlled by @option{-Wpedantic}. But I think the previous version is better here. Maybe at present your version is true, but in principle -Wpedantic can control warnings that aren't pedwarns. Some of the -Wformat warnings are conditional on having both -Wformat and -Wpedantic enabled - we can only represent those using OPT_Wformat in the warning calls at present, but there's at least as case for -Werror=pedantic to turn them into errors (while -pedantic-errors definitely should not turn them into errors, as the code is only invalid at runtime and is valid at compile time as long as it never gets executed).
On 17 October 2014 22:46, Joseph S. Myers <joseph@codesourcery.com> wrote: >> @@ -3318,8 +3327,8 @@ >> >> @item -pedantic-errors >> @opindex pedantic-errors >> -Like @option{-Wpedantic}, except that errors are produced rather than >> -warnings. >> +This is equivalent to @option{-Werror=pedantic} plus making into errors >> +a few warnings that are not controlled by @option{-Wpedantic}. > > But I think the previous version is better here. Maybe at present your > version is true, but in principle -Wpedantic can control warnings that > aren't pedwarns. Some of the -Wformat warnings are conditional on having > both -Wformat and -Wpedantic enabled - we can only represent those using > OPT_Wformat in the warning calls at present, but there's at least as case > for -Werror=pedantic to turn them into errors (while -pedantic-errors > definitely should not turn them into errors, as the code is only invalid > at runtime and is valid at compile time as long as it never gets > executed). The previous version also does not match your description. You are saying that -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) and -pedantic-errors = pedwarn(OPT_Wpedantic).+ pedwarn(0) The current version says that -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) and -pedantic-errors = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) My proposal says that: -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) and -pedantic-errors = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) + pedwarn(0) which perhaps is not how it should be, but it is strictly more correct in the sense that it is wrong in exactly the same thing but it is right in one more than the current version. Cheers, Manuel.
On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote: > The previous version also does not match your description. You are saying that > > -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) > and -pedantic-errors = pedwarn(OPT_Wpedantic).+ pedwarn(0) > > The current version says that > > -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) > and -pedantic-errors = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) > > My proposal says that: > > -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) > and -pedantic-errors = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) > + pedwarn(0) None of those three descriptions seems helpful here. The point of -pedantic is to give a diagnostic whenever the standard requires one (and possibly in some other cases). The point of -Werror=pedantic is to give an error for diagnostics enabled by -pedantic (whether or not the standard requires a diagnostic in those cases, and whether or not the standard requires successful translation in those cases). The point of -pedantic-errors is to give an error whenever the standard requires a diagnostic (and possibly in some other cases, but not cases where the standard requires successful translation).
On 18 October 2014 01:43, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote: > >> The previous version also does not match your description. You are saying that >> >> -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) >> and -pedantic-errors = pedwarn(OPT_Wpedantic).+ pedwarn(0) >> >> The current version says that >> >> -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) >> and -pedantic-errors = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) >> >> My proposal says that: >> >> -Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) >> and -pedantic-errors = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic) >> + pedwarn(0) > > None of those three descriptions seems helpful here. > > The point of -pedantic is to give a diagnostic whenever the standard > requires one (and possibly in some other cases). The point of > -Werror=pedantic is to give an error for diagnostics enabled by -pedantic > (whether or not the standard requires a diagnostic in those cases, and > whether or not the standard requires successful translation in those > cases). The point of -pedantic-errors is to give an error whenever the > standard requires a diagnostic (and possibly in some other cases, but not > cases where the standard requires successful translation). Can we make "possibly in some other cases" more concrete? Otherwise, the following seems already an improvement to me: @@ -3318,8 +3327,10 @@ @item -pedantic-errors @opindex pedantic-errors -Like @option{-Wpedantic}, except that errors are produced rather than -warnings. +Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) +requires a diagnostic. This is not equivalent to +@option{-Werror=pedantic}, since there are errors enabled by this option +and not enabled by the latter and vice versa. @item -Wall @opindex Wall Cheers, Manuel.
On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote:
> Can we make "possibly in some other cases" more concrete? Otherwise,
Cases where something about the code is not defined by the base standard,
but a diagnostic is not required. -pedantic may give a warning for such
cases. -pedantic-errors may give an error *if* there is compile-time
undefined behavior (not if the not-definedness is something other than
undefined behavior, or is undefined behavior only if the code in question
is executed, although it will still give a warning for such cases if
-pedantic does).
On 18 October 2014 02:13, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote: > >> Can we make "possibly in some other cases" more concrete? Otherwise, > > Cases where something about the code is not defined by the base standard, > but a diagnostic is not required. -pedantic may give a warning for such > cases. -pedantic-errors may give an error *if* there is compile-time > undefined behavior (not if the not-definedness is something other than > undefined behavior, or is undefined behavior only if the code in question > is executed, although it will still give a warning for such cases if > -pedantic does). What about this version? Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) requires a diagnostic, in cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard. This is not equivalent to @option{-Werror=pedantic}, since there are errors enabled by this option and not enabled by the latter and vice versa. Cheers, Manuel.
On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote: > What about this version? > > Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) > requires a diagnostic, in cases where there is undefined behavior at > compile-time Only in *some* such cases of compile-time undefined behavior.
On 19 October 2014 18:08, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote: > >> What about this version? >> >> Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) >> requires a diagnostic, in cases where there is undefined behavior at >> compile-time > > Only in *some* such cases of compile-time undefined behavior. New try: Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard. This is not equivalent to @option{-Werror=pedantic}, since there are errors enabled by this option and not enabled by the latter and vice versa. OK?
On Tue, 21 Oct 2014, Manuel López-Ibáñez wrote: > On 19 October 2014 18:08, Joseph S. Myers <joseph@codesourcery.com> wrote: > > On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote: > > > >> What about this version? > >> > >> Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) > >> requires a diagnostic, in cases where there is undefined behavior at > >> compile-time > > > > Only in *some* such cases of compile-time undefined behavior. > > New try: > > Give an error whenever the @dfn{base standard} (see @option{-Wpedantic}) > requires a diagnostic, in some cases where there is undefined behavior at > compile-time and in some other cases that do not prevent compilation of programs > that are valid according to the standard. This is not equivalent to > @option{-Werror=pedantic}, since there are errors enabled by this option > and not enabled by the latter and vice versa. > > OK? OK.
Index: invoke.texi =================================================================== --- invoke.texi (revision 215973) +++ invoke.texi (working copy) @@ -3263,6 +3263,15 @@ language-specific options also refer to @ref{C++ Dialect Options} and @ref{Objective-C and Objective-C++ Dialect Options}. +Some options, such as @option{-Wall} and @option{-Wextra}, turn on other +options, such as @option{-Wunused}, which may turn on further options, +such as @option{-Wunused-value}. The combined effect of positive and +negative forms is that more specific options have priority over less +specific ones, independently of their position in the command-line. For +options of the same specificity, the last one takes effect. Options +enabled or disabled via pragmas (@pxref{Diagnostic Pragmas}) take effect +as if they appeared at the end of the command-line. + When an unrecognized warning option is requested (e.g., @option{-Wunknown-warning}), GCC emits a diagnostic stating that the option is not recognized. However, if the @option{-Wno-} form @@ -3318,8 +3327,8 @@ @item -pedantic-errors @opindex pedantic-errors -Like @option{-Wpedantic}, except that errors are produced rather than -warnings. +This is equivalent to @option{-Werror=pedantic} plus making into errors +a few warnings that are not controlled by @option{-Wpedantic}. @item -Wall @opindex Wall