From: Richard Stallman <rms@gnu.org>
To: eric@siege-engine.com
Cc: cyd@stupidchicken.com, raeburn@raeburn.org, deng@randomsample.de,
emacs-devel@gnu.org
Subject: Re: CEDET merge question
Date: Mon, 14 Sep 2009 14:28:37 -0400 [thread overview]
Message-ID: <E1MnGI1-0000z5-HP@fencepost.gnu.org> (raw)
In-Reply-To: <1252863531.4770.230.camel@projectile.siege-engine.com> (eric@siege-engine.com)
Etags, ctags, gnu global, idutils and cscope all have parsers of some
sort that parse C and C++ code. Some use regexp matchers. Others have
primitive parsers.
gcc, of course, has a full language compliant parser which it uses to
compile code. I'm not a gcc expert, but I assume that as it parses, it
keeps track of the various symbols (functions, variables, namespaces,
etc) and where they are. (ie - debug info for gdb).
Now I know what you are talking about. This idea seems very
appealing, but it has a grave flaw. The flaw comes from the way GCC
handles input: it does preprocessing first, and real parsing operates
only on the output of preprocessing. So the output that GCC can
easily make would describe only the output of preprocessing.
Definitions and calls which are not actually compiled won't be seen at
all. Macros and references to them won't be seen at all.
What etags does now is much better, because it avoids that problem.
It is true that output from GCC would give more details about types,
etc., and would avoid getting confused in a few strange situations.
So there is indeed an advantage to generating the output from GCC.
But the disadvantage is much more important.
I designed a way to make GCC analyze and report on macros and on the
code that's not compiled in. That would get the best of both aspects.
But this is not a small job. Please don't ask me to write more
details unless you're prepared to do a substantial amount of work
and study the GCC parsing code carefully.
next prev parent reply other threads:[~2009-09-14 18:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-05 16:28 CEDET merge question Chong Yidong
2009-09-05 17:22 ` David Engster
2009-09-05 20:53 ` Chong Yidong
2009-09-05 23:08 ` David Engster
2009-09-06 15:37 ` Richard Stallman
2009-09-06 17:46 ` Ken Raeburn
2009-09-06 21:11 ` David Engster
2009-09-06 22:26 ` Ken Raeburn
2009-09-07 13:33 ` Richard Stallman
2009-09-12 12:49 ` Eric M. Ludlam
2009-09-12 13:37 ` Miles Bader
2009-09-13 16:39 ` Richard Stallman
2009-09-14 11:22 ` tomas
2009-09-14 12:15 ` Miles Bader
2009-09-14 20:04 ` tomas
2009-09-12 16:34 ` David Engster
2009-09-13 16:39 ` Richard Stallman
2009-09-13 17:38 ` Eric M. Ludlam
2009-09-14 18:28 ` Richard Stallman [this message]
2009-09-13 16:40 ` Richard Stallman
2009-09-07 13:34 ` Richard Stallman
2009-09-08 8:11 ` joakim
2009-09-08 9:07 ` Lennart Borgman
2009-09-08 9:09 ` Lennart Borgman
2009-09-08 14:41 ` Chong Yidong
2009-09-08 15:10 ` joakim
2009-09-08 17:18 ` Chong Yidong
2009-09-08 21:21 ` Romain Francoise
2009-09-08 22:27 ` Chong Yidong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1MnGI1-0000z5-HP@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=cyd@stupidchicken.com \
--cc=deng@randomsample.de \
--cc=emacs-devel@gnu.org \
--cc=eric@siege-engine.com \
--cc=raeburn@raeburn.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.