On Fri, 27 Nov 2020 at 15:57, emre brookes <brookes@xxxxxxxxxxx> wrote:
>
> emre brookes wrote:
> > Martin Sebor wrote:
> >> On 11/22/20 8:34 AM, emre brookes wrote:
> >>> I was compiling a project and received an odd message that took some
> >>> digging.
> >>> e.g.
> >>>
> >>> file.cpp:#:#: error: expected unqualified-id before numeric constant
> >>> # | if ( inttype == MyClass::ERROR )
> >>> ^~~~~
> >>> where MyClass::ERROR is an enum.
> >>>
> >>> Took some digging to find out ERROR was somewhere #define'd and the
> >>> cure was to #undef ERROR
> >>> Could never find out *where* it was defined - recursively searched
> >>> all include files of the project and /usr/include etc.
> >>> Regardless, it would have been very helpful to know in the error
> >>> messages that a #define was active or to have the ERROR replaced by
> >>> the macro substitution.
> >>>
> >>> Is it possible to get any macro expansion information in error
> >>> messages?
> >>> I didn't see a compiler flag for to get this information, but I
> >>> might have missed it.
> >>> If not, it would be a nice feature to have.
> >>
> >> I'd expect to see output similar to the below where the error points
> >> to the macro. I'm not sure under what conditions it won't (with some
> >> specific options perhaps?) If you can create an isolated test case
> >> showing it doesn't I'd recommend to open a bug in Bugzilla (or just
> >> follow up here).
> >>
> >> Martin
> >>
> >> $ cat a.C && gcc -S a.C
> >> struct MyClass { enum { ERROR = 1 }; };
> >>
> >> #define ERROR 1
> >>
> >> int f (int inttype)
> >> {
> >> if (inttype == MyClass::ERROR)
> >> return 0;
> >> return 1;
> >> }
> >> a.C: In function ‘int f(int)’:
> >> a.C:3:15: error: expected unqualified-id before numeric constant
> >> 3 | #define ERROR 1
> >> | ^
> >> a.C:7:27: note: in expansion of macro ‘ERROR’
> >> 7 | if (inttype == MyClass::ERROR)
> >> | ^~~~~
> >> a.C:7:25: error: expected ‘)’ before numeric constant
> >> 7 | if (inttype == MyClass::ERROR)
> >> | ~ ^
> >> | )
> >> .
> >>
> > I get the same results for your example code. Here gcc nicely
> > identifies the macro expansion :)
> > Will test later with compiler flags from the project's Makefile add
> > see if I can reproduce the issue I observed on a simple case.
> >
> > Thanks,
> > Emre
> Followup:
> strange error
>
> 555 0 mingw [eb@ebwin764] ~/gccerrortest $ gcc --version
> gcc.exe (Rev5, Built by MSYS2 project) 10.2.0
>
> key takeway -
> on msys2 64 bit
> macro expansion information is lost when the #define ERROR is in an
> include file in /mingw64/x86_64-w64-mingw32/include
> if i move the include file elsewhere (tested /usr/include and .) -
> normal behavior
> linux variants tested did not show this behavior
> centos 8 gcc (GCC) 9.2.1 20191120 (Red Hat 9.2.1-2)
> centos 8 gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
> ubuntu 20 gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
>
> Should I create a bugzilla for gcc? Might be some msys2 issue. Not sure.
I think this is the expected behaviour when the macro is defined in a
system header, although I'm not convinced it's useful. I think there's
already a bugzilla about it.
