CC Mode and GCC/CEDET integration for evaluating macros

CC Mode and GCC/CEDET integration for evaluating macros

[Oleh Krehel]

Hi all,

I just went through the whole CC Mode manual, just to make sure that I'm
not being silly asking for an existing feature.

I'd like to be able to evaluate the current symbolic constant at point
with "C-x C-e" for C/C++.  Moreover, I remember when I was using Visual
Studio 10 years ago, it had a feature of parsing the macros and graying
out #ifdef branches. I found a screenshot of this if it's not clear what
I mean: http://stackoverflow.com/questions/11610549/

I think it would be really cool to add both these features to CC Mode.
So I'd like to ask:

1. Is there any past progress towards these features?

2. How viable is it to implement them? Could they work for the most
common build systems?

3. Could / should they be implemented based on CEDET or GCC?

4. How hard would it be to actually do it all? Are there any predictable
roadblocks?

5. Would other people besides me find these features useful?

Oleh

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Alan Mackenzie]

Hello, Oleh.

I'm speaking here for CC Mode, not CEDET.

On Fri, May 01, 2015 at 07:03:05PM +0200, Oleh Krehel wrote:

> Hi all,

> I just went through the whole CC Mode manual, just to make sure that I'm
> not being silly asking for an existing feature.

> I'd like to be able to evaluate the current symbolic constant at point
> with "C-x C-e" for C/C++.

There's nothing like that in CC Mode.  But there is c-macro-expand in
cmacexp.el which might have something like this, or be easily hackable to
something like this.

> Moreover, I remember when I was using Visual Studio 10 years ago, it
> had a feature of parsing the macros and graying out #ifdef branches. I
> found a screenshot of this if it's not clear what I mean:
> http://stackoverflow.com/questions/11610549/

There is hide-ifdef-mode in Emacs which does something similar - It makes
the "non-active" bits of #ifdef branches invisible rather than changing
their appearance.  Doubtless it would be easy enough to add the "greying
out" facility as an option.

> I think it would be really cool to add both these features to CC Mode.

I'm not sure CC Mode would be the best place for these.  hide-ifdef-mode
nd c-macro-expand already exist.  I suggest you look at these first.

> So I'd like to ask:

> 1. Is there any past progress towards these features?

> 2. How viable is it to implement them? Could they work for the most
> common build systems?

> 3. Could / should they be implemented based on CEDET or GCC?

> 4. How hard would it be to actually do it all? Are there any predictable
> roadblocks?

> 5. Would other people besides me find these features useful?

> Oleh

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Oleh Krehel]

Hello Alan,

Thanks for the response, I'm really glad I asked first before trying to
hack up something on my own.

Alan Mackenzie <acm@muc.de> writes:

> On Fri, May 01, 2015 at 07:03:05PM +0200, Oleh Krehel wrote:
>
>> Hi all,
>
>> I just went through the whole CC Mode manual, just to make sure that I'm
>> not being silly asking for an existing feature.
>
>> I'd like to be able to evaluate the current symbolic constant at point
>> with "C-x C-e" for C/C++.
>
> There's nothing like that in CC Mode.  But there is c-macro-expand in
> cmacexp.el which might have something like this, or be easily hackable to
> something like this.

I tried c-macro-expand and it works well for macros defined within the
current file, and even for the standard stuff like __TIMESTAMP__.  But
it doesn't work, for instance for HAVE_PWD_H in editfns.c.  Do you know
if it could work? Is it just a matter of passing some include path to
the preprocessor call?

>> Moreover, I remember when I was using Visual Studio 10 years ago, it
>> had a feature of parsing the macros and graying out #ifdef branches. I
>> found a screenshot of this if it's not clear what I mean:
>> http://stackoverflow.com/questions/11610549/
>
> There is hide-ifdef-mode in Emacs which does something similar - It makes
> the "non-active" bits of #ifdef branches invisible rather than changing
> their appearance.  Doubtless it would be easy enough to add the "greying
> out" facility as an option.

It appears that `hide-ifdefs' hides them unconditionally.

>> I think it would be really cool to add both these features to CC Mode.
>
> I'm not sure CC Mode would be the best place for these.  hide-ifdef-mode
> nd c-macro-expand already exist.  I suggest you look at these first.

The functions exist, sure. But for most users they are invisible /
unknown unless they are bound in a keymap. `c-mode-map' is pretty
visible and would be a great way to promote these features.

Oleh

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Date: Fri, 01 May 2015 20:23:32 +0200
> Cc: emacs-devel@gnu.org
> 
> I tried c-macro-expand and it works well for macros defined within the
> current file, and even for the standard stuff like __TIMESTAMP__.  But
> it doesn't work, for instance for HAVE_PWD_H in editfns.c.  Do you know
> if it could work? Is it just a matter of passing some include path to
> the preprocessor call?

You need to pass it the same -I flags as used during the Emacs build,
see src/Makefile.

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Date: Fri, 01 May 2015 20:23:32 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> I tried c-macro-expand and it works well for macros defined within the
>> current file, and even for the standard stuff like __TIMESTAMP__.  But
>> it doesn't work, for instance for HAVE_PWD_H in editfns.c.  Do you know
>> if it could work? Is it just a matter of passing some include path to
>> the preprocessor call?
>
> You need to pass it the same -I flags as used during the Emacs build,
> see src/Makefile.

Thanks for the suggestion. I tried it and it didn't work. I've edited
src/Makefile.in to add:

echo_cflags:
	echo "$(ALL_CFLAGS)"

Here are the flags that I obtained and passed to `c-macro-expand':

-Demacs  -I. -I. -I../lib -I../lib   -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/inclu
de/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/inc
lude/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/
harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12   -I/usr/include/freet
ype2     -pthread -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.
0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/pixm
an-1 -I/usr/include/freetype2    -I/usr/include/libpng12 -I/usr/include/libxml2   -I/usr/include/dbus-1.
0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include      -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-l
inux-gnu/glib-2.0/include   -pthread -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-li
nux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -I/usr/i
nclude/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -I/usr/include/freetype2   -I/usr/include
/freetype2   -I/usr/include/freetype2

Is there a working / better way to get these flags. I wouldn't want to
reconfigure just to get the flags.

Oleh

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 01 May 2015 20:52:46 +0200
> 
> > You need to pass it the same -I flags as used during the Emacs build,
> > see src/Makefile.
> 
> Thanks for the suggestion. I tried it and it didn't work.

Sorry, I'm confused: what did you try, and how did it not work?

> Is there a working / better way to get these flags.

You could say "make -n fns.o -W fns.c", and process the output, I
guess.  In any case, src/Makefile is the only place where these flags
are recorded, so you must somehow ask Make to display them.

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: acm@muc.de,  emacs-devel@gnu.org
>> Date: Fri, 01 May 2015 20:52:46 +0200
>> 
>> > You need to pass it the same -I flags as used during the Emacs build,
>> > see src/Makefile.
>> 
>> Thanks for the suggestion. I tried it and it didn't work.
>
> Sorry, I'm confused: what did you try, and how did it not work?

I did (setq c-macro-prompt-flag t), marked HAVE_PWD_H with a region,
called `c-macro-expand', entered that huge "-I" expression that I got from
make. Got this:

c-macro-expansion: Search failed: "
??? !!! ??? start of c-macro expansion ??? !!! ???"

Oleh

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 01 May 2015 21:42:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Oleh Krehel <ohwoeowho@gmail.com>
> >> Cc: acm@muc.de,  emacs-devel@gnu.org
> >> Date: Fri, 01 May 2015 20:52:46 +0200
> >> 
> >> > You need to pass it the same -I flags as used during the Emacs build,
> >> > see src/Makefile.
> >> 
> >> Thanks for the suggestion. I tried it and it didn't work.
> >
> > Sorry, I'm confused: what did you try, and how did it not work?
> 
> I did (setq c-macro-prompt-flag t), marked HAVE_PWD_H with a region,
> called `c-macro-expand', entered that huge "-I" expression that I got from
> make. Got this:
> 
> c-macro-expansion: Search failed: "
> ??? !!! ??? start of c-macro expansion ??? !!! ???"

This generally means that cpp exited with some error, I think.  (yes,
the error message could be improved.)  I suggest to step with a
debugger through the relevant functions in cmacexp.el, it's possible
there's a bug there.

More to the point: I don't know what you mean, exactly, by "marked
HAVE_PWD_H with a region".  For a C preprocessor to produce something
reasonable, the region you mark should be valid C, so you should at
least include everything to and including the matching #endif in the
region.  If I do that, the command works for me, and produces a region
with the contents of <pwd.h> header, which means HAVE_PWD_H is defined
in my configuration.

Re: CC Mode and GCC/CEDET integration for evaluating macros

[martin rudalics]

 > There is hide-ifdef-mode in Emacs which does something similar - It makes
 > the "non-active" bits of #ifdef branches invisible rather than changing
 > their appearance.  Doubtless it would be easy enough to add the "greying
 > out" facility as an option.

See `hide-ifdef-shadow'.

martin

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Eli Zaretskii]

> Date: Sat, 02 May 2015 11:27:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: acm@muc.de, emacs-devel@gnu.org
> 
> > c-macro-expansion: Search failed: "
> > ??? !!! ??? start of c-macro expansion ??? !!! ???"
> 
> This generally means that cpp exited with some error, I think.  (yes,
> the error message could be improved.)  I suggest to step with a
> debugger through the relevant functions in cmacexp.el, it's possible
> there's a bug there.

In fact, there was indeed a bug in the code that handled abnormal exit
status of the preprocessor: it would bail out early without showing
the error messages emitted by the preprocessor, which are an important
clue as to what went wrong.  For example, if you don't pass any
options to the preprocessor, it fails with this error message:

  <stdin>:21:20: fatal error: config.h: No such file or directory
  compilation terminated.

which clearly suggests that you need to pass at least the -I. switch.

I fixed this.

Re: CC Mode and GCC/CEDET integration for evaluating macros

[Oleh Krehel]

martin rudalics <rudalics@gmx.at> writes:

>> There is hide-ifdef-mode in Emacs which does something similar - It makes
>> the "non-active" bits of #ifdef branches invisible rather than changing
>> their appearance.  Doubtless it would be easy enough to add the "greying
>> out" facility as an option.
>
> See `hide-ifdef-shadow'.

Thanks, it looks perfect. But it fails for this simple case (zero
includes, just from the top):

    #define IN  1
    #ifdef IN
    double foo;
    #endif

Here, "double foo;" gets the shadow. I called `hide-ifdefs'.

Oleh

Re: CC Mode and GCC/CEDET integration for evaluating macros

[martin rudalics]

 > But it fails for this simple case (zero
 > includes, just from the top):
 >
 >      #define IN  1
 >      #ifdef IN
 >      double foo;
 >      #endif
 >
 > Here, "double foo;" gets the shadow. I called `hide-ifdefs'.

Funny.  It doesn't get shadowed here.

But I've never got around to make `hide-ifdef-mode' work reasonably with
the Emacs code base.  I suppose that I'd have to set up some definitions
manually, then scan config.h and then scan the remaining header files in
the order they were processed by the compiler.  So if you could come up
with a solution, this would be very much appreciated here.

BTW, `hide-ifdef-mode' fails on my current config.h file with the trace
below.

martin

Debugger entered--Lisp error: (error "Bad token in parenthesized expression: L")
   signal(error ("Bad token in parenthesized expression: L"))
   error("Bad token in parenthesized expression: %s" L)
   hif-factor()
   hif-muldiv-expr()
   hif-math()
   hif-logshift-expr()
   hif-comp-expr()
   hif-eq-expr()
   hif-logand-expr()
   hif-logxor-expr()
   hif-logior-expr()
   hif-and-expr()
   hif-or-expr()
   hif-expr()
   hif-expr()
   hif-exprlist()
   hif-factor()
   hif-muldiv-expr()
   hif-math()
   hif-logshift-expr()
   hif-comp-expr()
   hif-eq-expr()
   hif-logand-expr()
   hif-logxor-expr()
   hif-logior-expr()
   hif-and-expr()
   hif-or-expr()
   hif-expr()
   hif-exprlist()
   hif-factor()
   hif-muldiv-expr()
   hif-math()
   hif-logshift-expr()
   hif-comp-expr()
   hif-eq-expr()
   hif-logand-expr()
   hif-logxor-expr()
   hif-logior-expr()
   hif-and-expr()
   hif-or-expr()
   hif-expr()
   hif-exprlist()
   hif-parse-exp((hif-lparen hif-lparen __GNUC__ hif-conditional hif-defined __GNUC_STDC_INLINE__ hif-and __GNUC_STDC_INLINE__ hif-colon hif-lparen 199901 L hif-less-equal __STDC_VERSION__ hif-and hif-not hif-defined __HP_cc hif-and hif-not hif-lparen hif-defined __SUNPRO_C hif-and __STDC__ hif-rparen hif-rparen hif-rparen hif-and hif-not hif-defined _GL_EXTERN_INLINE_STDHEADER_BUG hif-rparen))
   hif-canonicalize("\\(^\\|
\\)[ 	]*#[ 	]*if\\(n?def\\)?[ 	]+")
   hif-possibly-hide(nil)
   hide-ifdef-guts()
   hif-recurse-on(1099 58650)
   hif-possibly-hide(t)
   hide-ifdef-guts()
   hide-ifdefs()
   hide-ifdef-mode(toggle)
   funcall-interactively(hide-ifdef-mode toggle)
   call-interactively(hide-ifdef-mode record nil)
   command-execute(hide-ifdef-mode record)
   execute-extended-command(nil "hide-ifdef-mode" "hide-ifdef-mode")
   funcall-interactively(execute-extended-command nil "hide-ifdef-mode" "hide-ifdef-mode")
   call-interactively(execute-extended-command nil nil)
   command-execute(execute-extended-command)