[doc] Explain options precedence and difference between -pedantic-errors and -Werror=pedantic
diff mbox

Message ID CAESRpQBi5c6KCnyB3iR7OR_xHxsoe0tie2d-bP3xjuX6y273dg@mail.gmail.com
State New
Headers show

Commit Message

Manuel López-Ibáñez Oct. 17, 2014, 6:32 p.m. UTC
While writing the guidelines
https://gcc.gnu.org/wiki/Better_Diagnostics#guidelines , I noticed
that we never explain the precedence rules between conflicting
options. Also, the description of -pedantic-errors could be more
precise.

OK?

Comments

Joseph Myers Oct. 17, 2014, 8:46 p.m. UTC | #1
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).
Manuel López-Ibáñez Oct. 17, 2014, 11:31 p.m. UTC | #2
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.
Joseph Myers Oct. 17, 2014, 11:43 p.m. UTC | #3
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).
Manuel López-Ibáñez Oct. 18, 2014, 12:04 a.m. UTC | #4
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.
Joseph Myers Oct. 18, 2014, 12:13 a.m. UTC | #5
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).
Manuel López-Ibáñez Oct. 18, 2014, 4:39 p.m. UTC | #6
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.
Joseph Myers Oct. 19, 2014, 4:08 p.m. UTC | #7
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.
Manuel López-Ibáñez Oct. 21, 2014, 6:23 p.m. UTC | #8
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?
Joseph Myers Oct. 21, 2014, 9:57 p.m. UTC | #9
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.

Patch
diff mbox

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