Re: error: no newline at end of file
Manuel López-Ibáñez wrote: Then, if the warnings are not very useful but are mandated by the standard, I think that the sensible thing is to make them conditional on -pedantic. This way, people wanting strict diagnostics for nonconformant code can get them, while people that don't care about it don't need to suffer even a warning. I agree. For diagnostics for issues which (a) probably do not indicate mistakes on the part of the programmer, and (b) can be readily ignored by the compiler, the idiomatic handling is: if (pedantic) pedwarn (...); Thus, only users who want pedantic error messages see the message. They can control whether the message is an error or a warning via -pedantic-errors (or the C++ front-end's -fpermissive). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: error: no newline at end of file
On 01/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote: We have some real numbers about these new errors now. I've compiled the whole Debian archive in the last week for Gelato to test GCC 4.3 on IA64. Out of just slightly under 7000 packages in Debian, we have the following new failures: missing newline: 42 error: xxx redefined: 33 Martin, are those programs compiled with -pedantic or -pedantic-errors enabled? Cheers, Manuel.
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]: missing newline: 42 error: xxx redefined: 33 Martin, are those programs compiled with -pedantic or -pedantic-errors enabled? Nope. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]: missing newline: 42 error: xxx redefined: 33 Martin, are those programs compiled with -pedantic or -pedantic-errors enabled? Nope. Then, if the warnings are not very useful but are mandated by the standard, I think that the sensible thing is to make them conditional on -pedantic. This way, people wanting strict diagnostics for nonconformant code can get them, while people that don't care about it don't need to suffer even a warning. Just out of curiosity, does any of those programs use -Werror? Thanks again, Manuel.
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]: Just out of curiosity, does any of those programs use -Werror? No, otherwise the problems would have been found and fixed before. Remember, there has always been a warning about this, but now it's an error. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]: Just out of curiosity, does any of those programs use -Werror? No, otherwise the problems would have been found and fixed before. Remember, there has always been a warning about this, but now it's an error. Yes, you are right. Sorry, I forgot that Werror also affects pedwarns. Cheers, Manuel.
Re: error: no newline at end of file
We have some real numbers about these new errors now. I've compiled
the whole Debian archive in the last week for Gelato to test GCC 4.3
on IA64. Out of just slightly under 7000 packages in Debian, we have
the following new failures:
missing newline: 42
error: xxx redefined: 33
extra tokens at end of #else directive: 9
undefined reference: because of the change of the meaning of inline: 4
multiple definition: probably due to the change of inline, linking
against:
Apache: 1
libc6: 12
glib: 11
C++ header cleanup: 370 (I'll start filing bugs on packages...)
first argument of 'int main(unsigned int, char* const*)' should be 'int: 3
error: changes meaning of: 68
bugs I still need to investigate: 77
With regards to the pedwarnings, I suggest the following:
- The no newline and xxx redfined pedwarnings should be converted
into normal warnings. Rationale: no newline doesn't harm anyone and
there are quite a few programs that would fail because of an error
that many agree is too strict. Redefining something with -D seems
like an useful feature and again quite a few applications do this.
- extra tokens at end of #else directive: this is easy enough to
fix and only few programs do this. Let's keep this is as a pedwarn.
If people agree, I'll check in the following patch. OK?
Index: libcpp/macro.c
===
--- libcpp/macro.c (revision 123380)
+++ libcpp/macro.c (working copy)
@@ -1622,11 +1622,11 @@
if (warn_of_redefinition (pfile, node, macro))
{
- cpp_error_with_line (pfile, CPP_DL_PEDWARN, pfile-directive_line, 0,
+ cpp_error_with_line (pfile, CPP_DL_WARN, pfile-directive_line, 0,
\%s\ redefined, NODE_NAME (node));
if (node-type == NT_MACRO !(node-flags NODE_BUILTIN))
- cpp_error_with_line (pfile, CPP_DL_PEDWARN,
+ cpp_error_with_line (pfile, CPP_DL_WARN,
node-value.macro-line, 0,
this is the location of the previous definition);
}
Index: libcpp/lex.c
===
--- libcpp/lex.c(revision 123380)
+++ libcpp/lex.c(working copy)
@@ -854,7 +854,7 @@
{
/* Only warn once. */
buffer-next_line = buffer-rlimit;
- cpp_error_with_line (pfile, CPP_DL_PEDWARN,
pfile-line_table-highest_line,
+ cpp_error_with_line (pfile, CPP_DL_WARN,
pfile-line_table-highest_line,
CPP_BUF_COLUMN (buffer, buffer-cur),
no newline at end of file);
}
--
Martin Michlmayr
http://www.cyrius.com/
Re: error: no newline at end of file
Martin Michlmayr wrote: ... - The no newline and xxx redfined pedwarnings should be converted into normal warnings. Rationale: no newline doesn't harm anyone and there are quite a few programs that would fail because of an error that many agree is too strict. Redefining something with -D seems like an useful feature and again quite a few applications do this. I regret to say that the xxx redefined diagnostic *is* mandatory per C99 - 6.10.3p2: # Constraints # ... # An identifier currently defined as an object-like macro shall not be redefined by another # #define preprocessing directive unless the second definition is an object-like macro # definition and the two replacement lists are identical. Likewise, an identifier currently # defined as a function-like macro shall not be redefined by another #define # preprocessing directive unless the second definition is a function-like macro definition # that has the same number and spelling of parameters, and the two replacement lists are # identical. This therefore needs to stay a pedwarn at least for the case where the redefinition comes from a #define in the source. It's not clear to me whether the diagnostics you're talking about are from a redefinition via -D on the command line. I would be okay with suppressing the diagnostic altogether when there are two -D's on the command line -- the standard has nothing to say about command line behavior, and we generally make the later of two conflicting switches win. The right place to implement that would be warn_of_redefinition. [ Paging the Steering Committee: we need an actual cpplib maintainer. ] zw
Re: error: no newline at end of file
Zack Weinberg wrote: Martin Michlmayr wrote: ... - The no newline and xxx redfined pedwarnings should be converted into normal warnings. Rationale: no newline doesn't harm anyone and there are quite a few programs that would fail because of an error that many agree is too strict. Redefining something with -D seems like an useful feature and again quite a few applications do this. I regret to say that the xxx redefined diagnostic *is* mandatory per C99 - 6.10.3p2: How can the C99 standard have anything to say about the meaning of -D?
Re: error: no newline at end of file
* Zack Weinberg [EMAIL PROTECTED] [2007-04-01 08:30]: This therefore needs to stay a pedwarn at least for the case where the redefinition comes from a #define in the source. It's not clear to me whether the diagnostics you're talking about are from a redefinition via -D on the command line. No, the cases are combinations of #define in the code and -D on the command line. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
On 4/1/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Zack Weinberg [EMAIL PROTECTED] [2007-04-01 08:30]: This therefore needs to stay a pedwarn at least for the case where the redefinition comes from a #define in the source. It's not clear to me whether the diagnostics you're talking about are from a redefinition via -D on the command line. No, the cases are combinations of #define in the code and -D on the command line. Ugh. That puts us in the position of having to decide whether command line definitions count as previous definitions for 6.10.3p3. I'm inclined to think that they do, or rather, that saying they don't involves more bending of the language than I am comfortable with. I could be convinced otherwise. zw
Re: error: no newline at end of file
Ugh. That puts us in the position of having to decide whether command line definitions count as previous definitions for 6.10.3p3. 6.10.3p*2*. zw
Re: error: no newline at end of file
Zack Weinberg wrote: Ugh. That puts us in the position of having to decide whether command line definitions count as previous definitions for 6.10.3p3. I'm inclined to think that they do, or rather, that saying they don't involves more bending of the language than I am comfortable with. I could be convinced otherwise. It's not bending the language, the standard has nothing whatever to say about -D. I see no reason not to be completely permissive wrt -D if it is going to make transition smoother.
Re: error: no newline at end of file
On 4/1/07, Robert Dewar [EMAIL PROTECTED] wrote: Zack Weinberg wrote: It's not bending the language, the standard has nothing whatever to say about -D. I see no reason not to be completely permissive wrt -D if it is going to make transition smoother. The thing is, the standard does not read An identifier which has previously been defined by a #define directive shall not be redefined by another #define directive except as the same type of macro and with the same replacement-list. If it did, I would agree with you. Instead, it reads An identifier CURRENTLY DEFINED ... shall not be redefined by a #define directive (emphasis mine). The intent is, IMO, clearly to forbid (non-redundant) redefinition no matter how the identifier acquired a macro definition in the first place - whether by another #define, or by being built-in macros, or by -D. zw
Re: error: no newline at end of file
Ian Lance Taylor wrote: I agree, but what is happening now is that no newline at end of file is an error even when -pedantic is not specified. I don't think that is acceptable. I completely agree. The convention in the C++ front end is to say: if (pedantic) pedwarn (...); for things like this. As pedwarns are errors without -fpermissive, this eliminates the cases in which errors are generated for pedantic violations. The same approach should work here. I would certainly agree that the C++ front-end's handling of the various diagnostic levels is obscure, and should probably be overhauled at some point. But, this is it's current state, and it's been that way for a long time, so to resolve this issue, we should just play the same game. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: error: no newline at end of file
Andrew Pinski [EMAIL PROTECTED] writes: | On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote: | | In C, a pedwarn is a warning by default, an error with -pedantic-errors. | | | | In C++, a pedwarn is an error by default, a warning with -fpermissive. | | You're describing a defect, not the intended semantics. | | In C, a pedwarn is a warning by default, an error with -pedantic errors. | | In C++, a pedwarn is a warning by default, an error with -pedantic. | | This is not the first time this has come up. | In fact this was done on purpose back in 1998: | http://gcc.gnu.org/ml/gcc-patches/1998-12/msg00137.html That is the bit I was missing, and that explains my historical confusion about the change. Many thanks Andrew, and apologies to Joseph and others. [...] | * Messages about non-conformant code that we can still handle (pedwarns) | are now errors by default, rather than warnings. This can be reverted | with -fpermissive, and is overridden by -pedantic or -pedantic-errors. | | So I don't think this was a mistake or a bug at all. It was on | purpose for sure. Yes, definitely. -- Gaby
Re: error: no newline at end of file
Gabriel Dos Reis wrote: I don't understand your statement. The C++ (and the C) standard says # If a source file that is not empty does not end in a new-line # character, or ends in a new-line character immediately preceded by a # backslash character, the behavior is undefined. The GNU preprocessor has chosen to diagnose that for ages. That text as part of the C standard *doesn't* call for a mandatory diagnostic, though (it is not a violation of a shall phrase in a constraints section). The usual practice in the C front end is to reserve pedwarn() for mandatory diagnostics that we consider not worthy of errors. I don't know about the C++ standard or front end. In this particular case, I think we should downgrade from CPP_DL_PEDWARN to CPP_DL_WARNING, because it's not mandatory (at least in C) and it's a totally harmless thing to do. zw
Re: error: no newline at end of file
Zack Weinberg [EMAIL PROTECTED] writes: | Gabriel Dos Reis wrote: | I don't understand your statement. The C++ (and the C) standard says | | # If a source file that is not empty does not end in a new-line | # character, or ends in a new-line character immediately preceded by a | # backslash character, the behavior is undefined. | | The GNU preprocessor has chosen to diagnose that for ages. | | That text as part of the C standard *doesn't* call for a mandatory | diagnostic, though (it is not a violation of a shall phrase in a | constraints section). I was very careful in saying that the GNU preprocessor *has chosen* (as opposed to a diagnostic is required), to emit a diagnostic -- overall, I think it is a good thing. However, whether it should be a hard error or a warning I have no preference. What I did suggest, which turned out to be invalid, was that a pedwarn in C++ is a warning unless -pedantic. That was changed by a patch committed in 1998. If the new-line ending rule is found to be unacceptable (my editor always asks if I wanted to add one, so I did not get to realize adding one is too much), your suggestion: | In this particular case, I think we should downgrade from | CPP_DL_PEDWARN to CPP_DL_WARNING, because it's not mandatory (at least | in C) and it's a totally harmless thing to do. is fine -- I don't know who of you or Neil added the diagnostic classification -- as you're morally the CPP maintainer (we are missing one). -- Gaby
RE: error: no newline at end of file
On 27 March 2007 11:26, Martin Michlmayr wrote: Between 4.3.0 20070303 and 4.3.0 20070326 the no newline at end of file warning changed to an error. Interestingly enough, I cannot see any obvious change to libcpp/lex.c or the ChangeLog. Does anyone else see this and know whether this was intentional? I think this change is a bad idea since it doesn't gain us anything. Had this in my local version (3.3 series) for some time. If there's interest I could always up-port it for mainline. cheers, DaveK -- Can't think of a witty .sigline today Wno-eof-newline.diff Description: Binary data
Re: error: no newline at end of file
It is a pedantic warning. Pedantic warnings are warnings in C and errors in C++, unless you use -fpermissive. So if you are seeing this in C++, the change was intentional because PR24924 was fixed. If you are seeing it in C and you are not using pedantic-errors, then it is probably a bug. Cheers, Manuel. On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: Between 4.3.0 20070303 and 4.3.0 20070326 the no newline at end of file warning changed to an error. Interestingly enough, I cannot see any obvious change to libcpp/lex.c or the ChangeLog. Does anyone else see this and know whether this was intentional? I think this change is a bad idea since it doesn't gain us anything. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. If you are seeing it in C and you are not using pedantic-errors, then it is probably a bug. Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. I think it would be worth mentioning this on http://gcc.gnu.org/gcc-4.3/changes.html since quite a bit of C++ code is affected by this change. Manu, can you submit a patch for this? -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. If you are seeing it in C and you are not using pedantic-errors, then it is probably a bug. Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. I cannot answer why this is a pedwarn or why C++ emits pedantic errors by default. I only made current behaviour more consistent and fixed an open and confirmed bug (one less, 2700 to go). Cheers, Manuel.
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]: Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. I cannot answer why this is a pedwarn or why C++ emits pedantic errors by default. Sorry for not being clearer; this question wasn't specifically directed at you. Hopefully someone else, maybe Joseph, can answer it. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. I think it would be worth mentioning this on http://gcc.gnu.org/gcc-4.3/changes.html since quite a bit of C++ code is affected by this change. Manu, can you submit a patch for this? I can submit a patch saying that: C++ preprocessor emits errors by default for nonconformant code, following the C++ frot-end default behaviour. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. Does it sound right to you? Manuel.
Re: error: no newline at end of file
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]: Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. I cannot answer why this is a pedwarn or why C++ emits pedantic errors by default. Sorry for not being clearer; this question wasn't specifically directed at you. Hopefully someone else, maybe Joseph, can answer it. Nevertheless, if this is indeed a diagnostic required by the standard, perhaps we should just conditionalize it on the presence of -pedantic in the command-line (rather than being unconditional as it is now). Cheers, Manuel.
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]: C++ preprocessor emits errors by default for nonconformant code, following the C++ frot-end default behaviour. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. s/frot-end/front-end/ I'm not sure whether nonconformant code is specific enough. Apart from this, it looks good. -- Martin Michlmayr http://www.cyrius.com/
Re: error: no newline at end of file
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]: C++ preprocessor emits errors by default for nonconformant code, following the C++ frot-end default behaviour. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. s/frot-end/front-end/ I'm not sure whether nonconformant code is specific enough. Apart from this, it looks good. It comes from the definition of fpermissive in invoke.texi. Cheers, Manuel.
Re: error: no newline at end of file
Martin Michlmayr [EMAIL PROTECTED] writes: | * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: | So if you are seeing this in C++, the change was intentional because | PR24924 was fixed. If you are seeing it in C and you are not using | pedantic-errors, then it is probably a bug. | | Thanks for the explanation - this explains what I'm seeing. Is there | a good reason against changing this particular warning from | CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail | to build because of this and it seems overly strict to me. However, if | it'll remain an error with C++ code, I'll start filing bugs on these | packages. -pedantic asks for strict checking of rules. User should accept correcting their codes (or used codes) with they ask for strict checking. -- Gaby
Re: error: no newline at end of file
Gabriel Dos Reis [EMAIL PROTECTED] writes: Martin Michlmayr [EMAIL PROTECTED] writes: | * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: | So if you are seeing this in C++, the change was intentional because | PR24924 was fixed. If you are seeing it in C and you are not using | pedantic-errors, then it is probably a bug. | | Thanks for the explanation - this explains what I'm seeing. Is there | a good reason against changing this particular warning from | CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail | to build because of this and it seems overly strict to me. However, if | it'll remain an error with C++ code, I'll start filing bugs on these | packages. -pedantic asks for strict checking of rules. User should accept correcting their codes (or used codes) with they ask for strict checking. I agree, but what is happening now is that no newline at end of file is an error even when -pedantic is not specified. I don't think that is acceptable. Ian
Re: error: no newline at end of file
* Gabriel Dos Reis [EMAIL PROTECTED] [2007-03-27 09:33]: -pedantic asks for strict checking of rules. User should accept correcting their codes (or used codes) with they ask for strict checking. They didn't ask for it because G++ does it by default. -- Martin Michlmayr http://www.cyrius.com/
RE: error: no newline at end of file
On 27 March 2007 16:07, Ian Lance Taylor wrote: Gabriel Dos Reis [EMAIL PROTECTED] writes: Martin Michlmayr [EMAIL PROTECTED] writes: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. If you are seeing it in C and you are not using pedantic-errors, then it is probably a bug. Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. -pedantic asks for strict checking of rules. User should accept correcting their codes (or used codes) with they ask for strict checking. I agree, but what is happening now is that no newline at end of file is an error even when -pedantic is not specified. I don't think that is acceptable. Ian I just stumbled across enhancement request PR14331, which is for this same feature. I think I should update my old patch and submit it. I could use a little advice about the best way to add a new preprocessor option flag setting; my original patch crudely adds a new global warning flag and then copies it into a member in the cpp options struct during c_common_post_options, which I think is probably not The Right Thing To Do(TM), and I haven't even studied the 4.x options-handling mechanisms yet, but what Manuel wrote in that PR implies that they have changed a bit since 3.3. cheers, DaveK -- Can't think of a witty .sigline today
Re: error: no newline at end of file
On 27/03/07, Dave Korn [EMAIL PROTECTED] wrote: On 27 March 2007 16:07, Ian Lance Taylor wrote: Gabriel Dos Reis [EMAIL PROTECTED] writes: Martin Michlmayr [EMAIL PROTECTED] writes: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. If you are seeing it in C and you are not using pedantic-errors, then it is probably a bug. Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. -pedantic asks for strict checking of rules. User should accept correcting their codes (or used codes) with they ask for strict checking. I agree, but what is happening now is that no newline at end of file is an error even when -pedantic is not specified. I don't think that is acceptable. Ian I just stumbled across enhancement request PR14331, which is for this same feature. I think I should update my old patch and submit it. I still think that the best solution is to make the warning conditional on the presence of an explicit -pedantic at the command-line. Cheers, Manuel.
Re: error: no newline at end of file
Ian Lance Taylor [EMAIL PROTECTED] writes: | Gabriel Dos Reis [EMAIL PROTECTED] writes: | | Martin Michlmayr [EMAIL PROTECTED] writes: | | | * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]: | | So if you are seeing this in C++, the change was intentional because | | PR24924 was fixed. If you are seeing it in C and you are not using | | pedantic-errors, then it is probably a bug. | | | | Thanks for the explanation - this explains what I'm seeing. Is there | | a good reason against changing this particular warning from | | CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail | | to build because of this and it seems overly strict to me. However, if | | it'll remain an error with C++ code, I'll start filing bugs on these | | packages. | | -pedantic asks for strict checking of rules. User should accept | correcting their codes (or used codes) with they ask for strict checking. | | I agree, but what is happening now is that no newline at end of file | is an error even when -pedantic is not specified. I don't think that | is acceptable. Then something is odd. A pedwarn is an error only when -pedantic, otherwise it should be just an unconditional warning. -- Gaby
Re: error: no newline at end of file
Martin Michlmayr [EMAIL PROTECTED] writes: | * Gabriel Dos Reis [EMAIL PROTECTED] [2007-03-27 09:33]: | -pedantic asks for strict checking of rules. User should accept | correcting their codes (or used codes) with they ask for strict | checking. | | They didn't ask for it because G++ does it by default. -pedantic transforms a pedwarn into an error -- otherwise the diagnostic remains an unconditional warning. If it is an unconditional error, then something is odd in the setting of flags. -- Gaby
Re: error: no newline at end of file
* Manuel López-Ibáñez: C++ preprocessor emits errors by default for nonconformant code, following the C++ frot-end default behaviour. Neither the C standard nor the C++ standard imposes any requirements on concrete source code representation, so it's not quite right to blame this issue on nonconformant code. Unless there are other compilers which require a LF character at the end of a file by default (and following this rule would increase portability as a result), I don't think it's a good idea to impose such a backwards incompatibility on users.
Re: error: no newline at end of file
Florian Weimer [EMAIL PROTECTED] writes: | * Manuel López-Ibáñez: | | C++ preprocessor emits errors by default for nonconformant code, | following the C++ frot-end default behaviour. | | Neither the C standard nor the C++ standard imposes any requirements | on concrete source code representation, so it's not quite right to | blame this issue on nonconformant code. I don't understand your statement. The C++ (and the C) standard says # If a source file that is not empty does not end in a new-line # character, or ends in a new-line character immediately preceded by a # backslash character, the behavior is undefined. The GNU preprocessor has chosen to diagnose that for ages. Why is that an issue now? -- Gaby
Re: error: no newline at end of file
Gabriel Dos Reis [EMAIL PROTECTED] writes: Florian Weimer [EMAIL PROTECTED] writes: | Neither the C standard nor the C++ standard imposes any requirements | on concrete source code representation, so it's not quite right to | blame this issue on nonconformant code. I don't understand your statement. The C++ (and the C) standard says # If a source file that is not empty does not end in a new-line # character, or ends in a new-line character immediately preceded by a # backslash character, the behavior is undefined. The GNU preprocessor has chosen to diagnose that for ages. Why is that an issue now? I don't think we necessarily have to change anything. But I think that Florian's point is that we don't have to confuse the concrete implementation with the abstract source representation. We could define gcc such that when it sees a concrete file which does not end in ASCII 0x0a, it automatically appends ASCII 0x0a in the abstract representation. This is not inherently different from the way we currently treat backslash space newline (ASCII 0x5c 0x20 0x0a) as identical to backslash newline (ASCII 0x5c 0x0a), and treat the newline as being quoted. Ian
Re: error: no newline at end of file
On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote: On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]: C++ preprocessor emits errors by default for nonconformant code, following the C++ frot-end default behaviour. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. s/frot-end/front-end/ I'm not sure whether nonconformant code is specific enough. Apart from this, it looks good. It comes from the definition of fpermissive in invoke.texi. Users aren't going to know from this language what has changed. Manuel, since you're the guy who has been studying the warnings lately: which other preprocessor diagnostics, other than no newline at end of file, are affected by this change? I would suggest language like: Certain nonconformant code detected by the C++ preprocessor, such as no newline at end of file, that were formerly warnings are now hard errors. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. If there are two or three more, the affected diagnostics could be listed as bullet items.
Re: error: no newline at end of file
On Tue, Mar 27, 2007 at 02:11:21PM +0100, Manuel López-Ibáñez wrote: On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]: Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. I cannot answer why this is a pedwarn or why C++ emits pedantic errors by default. Sorry for not being clearer; this question wasn't specifically directed at you. Hopefully someone else, maybe Joseph, can answer it. Nevertheless, if this is indeed a diagnostic required by the standard, perhaps we should just conditionalize it on the presence of -pedantic in the command-line (rather than being unconditional as it is now). It is not required by the standard to diagnose all undefined behavior. I've used operating systems in the ancient past (e.g. VMS) where it might not even be possible to issue the diagnostic, because there are file types for which the preprocessor would not even see the partial line. (I knew the acronym RMS as Record Management Services before I ever heard of a certain person who started a certain compiler).
Re: error: no newline at end of file
* Ian Lance Taylor: I don't think we necessarily have to change anything. Yes, I think that the standard does not require a particular approach to this problem. But I think that Florian's point is that we don't have to confuse the concrete implementation with the abstract source representation. We could define gcc such that when it sees a concrete file which does not end in ASCII 0x0a, it automatically appends ASCII 0x0a in the abstract representation. Exactly. During the first translation phase, end-of-line indicators are converted to new-line characters. If the majority of compilers treats end-of-file as an end-of-line indicator (which wouldn't surprise me), GCC can and should follow the crowd.
Re: error: no newline at end of file
On Tue, Mar 27, 2007 at 09:47:35AM -0700, Joe Buck wrote: On Tue, Mar 27, 2007 at 02:11:21PM +0100, Manuel López-Ibáñez wrote: On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]: Thanks for the explanation - this explains what I'm seeing. Is there a good reason against changing this particular warning from CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail to build because of this and it seems overly strict to me. However, if it'll remain an error with C++ code, I'll start filing bugs on these packages. I cannot answer why this is a pedwarn or why C++ emits pedantic errors by default. Sorry for not being clearer; this question wasn't specifically directed at you. Hopefully someone else, maybe Joseph, can answer it. Nevertheless, if this is indeed a diagnostic required by the standard, perhaps we should just conditionalize it on the presence of -pedantic in the command-line (rather than being unconditional as it is now). It is not required by the standard to diagnose all undefined behavior. I've used operating systems in the ancient past (e.g. VMS) where it might not even be possible to issue the diagnostic, because there are file types for which the preprocessor would not even see the partial line. Yes. In the original C89 standard discussions, one of the problems was how to describe the input in the face of record oriented systems, including systems that had virtual card readers, etc. The problem comes out of the phases of translation (5.1.1.2 in the C99 standard, should be close in the C90 standard). In particular, in paragraph 3, it says: A source file shall not end in a partial preprocessing token or a partial comment... If there is no trailing (logical) newline, then the file would end in a partial preprocessing token. (I knew the acronym RMS as Record Management Services before I ever heard of a certain person who started a certain compiler). -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: error: no newline at end of file
On Tue, 27 Mar 2007, Michael Meissner wrote: translation (5.1.1.2 in the C99 standard, should be close in the C90 standard). In particular, in paragraph 3, it says: A source file shall not end in a partial preprocessing token or a partial comment... If there is no trailing (logical) newline, then the file would end in a partial preprocessing token. As has been extensively discussed without resolution, the reference to a partial preprocessing token in the standard is defective: there is no such thing because of the rule that a preprocessing token is always the maximum sequence of characters forming a valid preprocessing token. -- Joseph S. Myers [EMAIL PROTECTED]
Re: error: no newline at end of file
On 27/03/07, Joe Buck [EMAIL PROTECTED] wrote: On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote: On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]: C++ preprocessor emits errors by default for nonconformant code, following the C++ frot-end default behaviour. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. s/frot-end/front-end/ I'm not sure whether nonconformant code is specific enough. Apart from this, it looks good. It comes from the definition of fpermissive in invoke.texi. Users aren't going to know from this language what has changed. Manuel, since you're the guy who has been studying the warnings lately: which other preprocessor diagnostics, other than no newline at end of file, are affected by this change? I would suggest language like: Certain nonconformant code detected by the C++ preprocessor, such as no newline at end of file, that were formerly warnings are now hard errors. Users can use the -fpermissive option to downgrade these diagnostics from errors to warnings. If there are two or three more, the affected diagnostics could be listed as bullet items. There aren't two or three. Any pedwarn has become an error. That is how the C++ front-end works. Perhaps it is not how the C++ front-end was intended to work but I have checked the C++ front-end code and it does indeed emit errors for pedwarns even when -pedantic was not given in the command line. [EMAIL PROTECTED]:~/src/trunk$ cat /home/manuel/src/test.cc extern void f(void); static void f(void); [EMAIL PROTECTED]:~/src/trunk$ /n/b01/guerby/release/3.4.6/bin/g++ -c ~/src/test.cc /home/manuel/src/test.cc:3: error: `void f()' was declared `extern' and later `static' /home/manuel/src/test.cc:1: error: previous declaration of `void f()' [EMAIL PROTECTED]:~/src/trunk$ /n/b01/guerby/release/3.4.6/bin/g++ -fpermissive -c ~/src/test.cc /home/manuel/src/test.cc:3: warning: `void f()' was declared `extern' and later `static' /home/manuel/src/test.cc:1: warning: previous declaration of `void f()' In GCC 4.3 the C++ preprocessor works like the C++ front-end, pedwarns are errors by default. Now, if the C++ front-end behaviour was already incorrect, that is a different issue altogether. Fixing this in both the C++ front-end and preprocessor seems fairly simple to me, if that is what we really want to do but it is going to change from errors to warnings a lot of pedwarns that have been errors since GCC 3.4.6 at least. I think we should consider this first and once there is a decision made, we can think about what to say in the changes page and what to do with the nonewline warning. Cheers, Manuel.
Re: error: no newline at end of file
On 27 Mar 2007 11:53:18 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote: Joe Buck [EMAIL PROTECTED] writes: | On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote: | On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: | * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]: | C++ preprocessor emits errors by default for nonconformant code, | following the C++ frot-end default behaviour. Users can use the | -fpermissive option to downgrade these diagnostics from errors to | warnings. | | s/frot-end/front-end/ | | I'm not sure whether nonconformant code is specific enough. Apart | from this, it looks good. | | It comes from the definition of fpermissive in invoke.texi. | | Users aren't going to know from this language what has changed. Manuel, | since you're the guy who has been studying the warnings lately: which | other preprocessor diagnostics, other than no newline at end of file, | are affected by this change? I believe there is a bug in the diagnostic flag setting. A pedwarn is a warning by default. It becomes a hard error only if -pedantic. If that is not happening, then we have a bug. Then we have a bug indeed. Since 3.4.6 at least. Notice that such a change is going to downgrade a lot of current errors to warnings. Nonetheless, if you really think it is a bug, I am willing to prepare a patch to fix it in both the front-end and the preprocessor. Cheers, Manuel.
Re: error: no newline at end of file
Quoting Manuel López-Ibáñez [EMAIL PROTECTED]: On 27 Mar 2007 11:53:18 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote: Joe Buck [EMAIL PROTECTED] writes: | On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel L=F3pez-Ib=E1=F1ez wro= te: | On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote: | * Manuel L=F3pez-Ib=E1=F1ez [EMAIL PROTECTED] [2007-03-27 14:0= 8]: | C++ preprocessor emits errors by default for nonconformant code, | following the C++ frot-end default behaviour. Users can use the | -fpermissive option to downgrade these diagnostics from errors to | warnings. | | s/frot-end/front-end/ | | I'm not sure whether nonconformant code is specific enough. Apart | from this, it looks good. | | It comes from the definition of fpermissive in invoke.texi. | | Users aren't going to know from this language what has changed. Manuel= , | since you're the guy who has been studying the warnings lately: which | other preprocessor diagnostics, other than no newline at end of file, | are affected by this change? I believe there is a bug in the diagnostic flag setting. A pedwarn is a warning by default. It becomes a hard error only if -pedantic. If that is not happening, then we have a bug. Then we have a bug indeed. Since 3.4.6 at least. Notice that such a change is going to downgrade a lot of current errors to warnings. my understanding of pedwarn (since over a decade) is I explained. Now, if we do have some good diagnostics, we should not lose them, as a matter of restoring the traditional meaning of pedwarns. Do you have an approximate list of those diagnostics? Nonetheless, if you really think it is a bug, I am willing to prepare a patch to fix it in both the front-end and the preprocessor. If a pedwarn is an error without -pedantic, then we have a bug. Cheers, Manuel.
Re: error: no newline at end of file
On Wed, Mar 28, 2007 at 01:23:45AM +, Joseph S. Myers wrote: In C, a pedwarn is a warning by default, an error with -pedantic-errors. In C++, a pedwarn is an error by default, a warning with -fpermissive. OK, so the change is that pedwarns from the preprocessor were previously warnings by default in C++, and were made errors to match the rest of C++? I suppose that makes sense, but I think it's an item for the release notes, so people are warned that they might have some cleaning to do.
Re: error: no newline at end of file
On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote: my understanding of pedwarn (since over a decade) is I explained. Now, if we do have some good diagnostics, we should not lose them, as a matter of restoring the traditional meaning of pedwarns. Do you have an approximate list of those diagnostics? Nonetheless, if you really think it is a bug, I am willing to prepare a patch to fix it in both the front-end and the preprocessor. If a pedwarn is an error without -pedantic, then we have a bug. In C, a pedwarn is a warning by default, an error with -pedantic-errors. In C++, a pedwarn is an error by default, a warning with -fpermissive. This is completely independent of whether a particular pedwarn call in the source is executed at runtime. Some are unconditional, and some only occur if -pedantic. -- Joseph S. Myers [EMAIL PROTECTED]
Re: error: no newline at end of file
Joseph S. Myers [EMAIL PROTECTED] writes: | On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote: | | my understanding of pedwarn (since over a decade) is I explained. | Now, if we do have some good diagnostics, we should not lose them, | as a matter of restoring the traditional meaning of pedwarns. | Do you have an approximate list of those diagnostics? | | Nonetheless, if you really think it is a bug, I am willing to prepare | a patch to fix it in both the front-end and the preprocessor. | | If a pedwarn is an error without -pedantic, then we have a bug. | | In C, a pedwarn is a warning by default, an error with -pedantic-errors. | | In C++, a pedwarn is an error by default, a warning with -fpermissive. You're describing a defect, not the intended semantics. In C, a pedwarn is a warning by default, an error with -pedantic errors. In C++, a pedwarn is a warning by default, an error with -pedantic. -- Gaby
Re: error: no newline at end of file
On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote: | In C, a pedwarn is a warning by default, an error with -pedantic-errors. | | In C++, a pedwarn is an error by default, a warning with -fpermissive. You're describing a defect, not the intended semantics. In C, a pedwarn is a warning by default, an error with -pedantic errors. In C++, a pedwarn is a warning by default, an error with -pedantic. This is not the first time this has come up. In fact this was done on purpose back in 1998: http://gcc.gnu.org/ml/gcc-patches/1998-12/msg00137.html http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01060.html http://gcc.gnu.org/ml/gcc/2004-10/msg00680.html http://gcc.gnu.org/ml/gcc/2004-09/msg01200.html etc. Also the first change listed on :): http://gcc.gnu.org/gcc-2.95/c++features.html * Messages about non-conformant code that we can still handle (pedwarns) are now errors by default, rather than warnings. This can be reverted with -fpermissive, and is overridden by -pedantic or -pedantic-errors. So I don't think this was a mistake or a bug at all. It was on purpose for sure. -- Pinski
