public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/48839] New: #error should terminate compilation - similar to missing #include
@ 2011-05-01 15:49 john.salmon at deshaw dot com
  2011-09-25 11:12 ` [Bug preprocessor/48839] " paolo.carlini at oracle dot com
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: john.salmon at deshaw dot com @ 2011-05-01 15:49 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

           Summary: #error should terminate compilation - similar to
                    missing #include
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: john.salmon@deshaw.com


bug 15638 established the policy that a missing #include terminates a
compilation.

I would suggest that encountering an #error should be immediately fatal, in
just the same way, and for exactly the same reasons.

A specific use-case:  I've used something autoconf-like to tell me whether
C++0x-style auto is supported.  Then I write this in my source file:

#ifndef HAVE_CXX0X_AUTO
#error This file requires the auto feature of C++0x
#endif
// lots of code that uses auto.

When I compile it with -std=c++98, I get the initial error message, and then
thousands of lines of complaints about syntax errors in the rest of the file. 
It would be far better to stop after the #error.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
@ 2011-09-25 11:12 ` paolo.carlini at oracle dot com
  2014-12-22 16:33 ` egall at gwmail dot gwu.edu
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-09-25 11:12 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |paolo.carlini at oracle dot
                   |                            |com
          Component|c++                         |preprocessor

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-25 11:07:49 UTC ---
Personally, I agree. Actually, I had to work around this behavior in the
library headers by changing the macros to something like:

#ifndef HAVE_CXX0X_AUTO
#error This file requires the auto feature of C++0x
#else
// lots of code that uses auto.
#endif

Note, this doesn't seem C++ specific, is a preprocessor issue. I'd like to hear
Jason about this.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
  2011-09-25 11:12 ` [Bug preprocessor/48839] " paolo.carlini at oracle dot com
@ 2014-12-22 16:33 ` egall at gwmail dot gwu.edu
  2014-12-22 17:35 ` jason at gcc dot gnu.org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: egall at gwmail dot gwu.edu @ 2014-12-22 16:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager <egall at gwmail dot gwu.edu> ---
I have been working around this by using the -Wfatal-errors flag when relevant,
but I agree that an actual fix would be better than the workaround...


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
  2011-09-25 11:12 ` [Bug preprocessor/48839] " paolo.carlini at oracle dot com
  2014-12-22 16:33 ` egall at gwmail dot gwu.edu
@ 2014-12-22 17:35 ` jason at gcc dot gnu.org
  2014-12-22 18:52 ` paolo.carlini at oracle dot com
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: jason at gcc dot gnu.org @ 2014-12-22 17:35 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
Makes sense to me.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
                   ` (2 preceding siblings ...)
  2014-12-22 17:35 ` jason at gcc dot gnu.org
@ 2014-12-22 18:52 ` paolo.carlini at oracle dot com
  2022-09-23 13:18 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: paolo.carlini at oracle dot com @ 2014-12-22 18:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joseph at codesourcery dot com

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks. I think the patch proper could be something as simple as the below, but
quite a few C testcases would require updating. I'd like to hear Joseph too
before the next steps.

Index: directives.c
===================================================================
--- directives.c    (revision 219024)
+++ directives.c    (working copy)
@@ -1103,7 +1103,7 @@ do_diagnostic (cpp_reader *pfile, int code, int re
 static void
 do_error (cpp_reader *pfile)
 {
-  do_diagnostic (pfile, CPP_DL_ERROR, 0, 1);
+  do_diagnostic (pfile, CPP_DL_FATAL, 0, 1);
 }

 static void


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
                   ` (3 preceding siblings ...)
  2014-12-22 18:52 ` paolo.carlini at oracle dot com
@ 2022-09-23 13:18 ` redi at gcc dot gnu.org
  2023-02-23 20:38 ` pinskia at gcc dot gnu.org
  2023-02-23 20:45 ` pinskia at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-23 13:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #8)
> about the other compilers? For sure some are following the current gcc
> behaviour, for compatibility, I suspect ICC for example. Should we also have
> a command line switch? Probably missing #includes just unconditionally end
> the compilation on most compilers, though. Well, it's also true that the so
> called workaround which I mentioned in Comment #1 works pretty well and we
> do have *very* few fatal errors in the front ends...

Clang keeps going, like GCC. ICC seems to as well.

But EDG stops immediately with a "catastrophic error":

"foo.cc", line 1: catastrophic error: #error directive: NOPE


Anyway, I don't think compatibility is an issue. We're not going to produce any
assembly or other output, compilation fails.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
                   ` (4 preceding siblings ...)
  2022-09-23 13:18 ` redi at gcc dot gnu.org
@ 2023-02-23 20:38 ` pinskia at gcc dot gnu.org
  2023-02-23 20:45 ` pinskia at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-23 20:38 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|paolo.carlini at oracle dot com    |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Paolo has not been around for the last 3 years so unassigning this bug report
from him so someone else can take it if they want. The patch against libcpp is
simple but the testsuite needs to updated or improved.
It also might make sense to have this as an option instead; though
-Wfatal-errors might be enough for that ... (maybe just an improved
documentation for #error in the cpp manual is needed for this change in the
end).

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
  2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
                   ` (5 preceding siblings ...)
  2023-02-23 20:38 ` pinskia at gcc dot gnu.org
@ 2023-02-23 20:45 ` pinskia at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-23 20:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note C23 has the following under "4. Conformance":
The implementation shall not successfully translate a preprocessing translation
unit containing a
#error preprocessing directive unless it is part of a group skipped by
conditional inclusion.

GCC does error out when preprocessing seperately from compiling but when doing
a combined, GCC does "successfully" translate the preprocessing translation but
does not finish compiling though. But maybe that is still valid.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-02-23 20:45 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-01 15:49 [Bug c++/48839] New: #error should terminate compilation - similar to missing #include john.salmon at deshaw dot com
2011-09-25 11:12 ` [Bug preprocessor/48839] " paolo.carlini at oracle dot com
2014-12-22 16:33 ` egall at gwmail dot gwu.edu
2014-12-22 17:35 ` jason at gcc dot gnu.org
2014-12-22 18:52 ` paolo.carlini at oracle dot com
2022-09-23 13:18 ` redi at gcc dot gnu.org
2023-02-23 20:38 ` pinskia at gcc dot gnu.org
2023-02-23 20:45 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).