Re: CEDET merge question

["Eric M. Ludlam" <eric@siege-engine.com>]

On Sun, 2009-09-13 at 12:39 -0400, Richard Stallman wrote:
> A very similar question to "why not make bison support Emacs Lisp
>     output", is "why not have gcc support tagging output".
> 
> Could you please explain what you mean by that?

Sure.

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).

As such, it should be possible for gcc to easily output text
representing a tags file.  Etags style would be fairly simple.  The
output of exuberant ctags is more complex.  The data needed by CEDET is
more complex still, but is still a subset of everything that gcc needs
to know.

For CEDET, if gcc saw this file:

-------------
int main(int argc, char *argv[]) {
}
-------------

it would be handy (for my application) for it to output:

--------------
(("main" function
  (:arguments
   (("argc" variable (:type "int") [ 11 20 ])
    ("argv" variable (:pointer 1 :dereference 1 :type "char") 
            [ 21 34] ))
   :type "int")
  [2 38]))
---------------

though, to be honest, any text output that is very regular would be
fine.

The part that makes this imperfect is that in Emacs, a file that needs
parsing may be in the middle of an edit.  Handling these cases can be a
bit tricky for my simplified parser, and gcc doesn't have that editing
information available.

To handle this, the CEDET tools have different ways to parse files, such
as "on save", and can track when a file is unparsable and take alternate
actions when that happens.

Eric