Re: Emacs contributions, C and Lisp

[David Engster <deng@randomsample.de>]

Helmut Eller writes:
> On Sun, Jan 11 2015, David Engster wrote:
>
>> AFAIK, this is not possible with a mere GCC
>> plugin.
>
> So what was your plan (or code, if any) before you abandoned this
> project?

The first step would have been to replace our existing C++ parser with
the AST that is produced by GCC. The plugin would output the same LISP
structures that Semantic uses. My work so far was mainly to investigate
how C++ types are actually stored in the AST. Especially the template
stuff is pretty weird, and documentation is sparse. Fortunately, the
headers are pretty well commented, but it still involves a *lot* of
trial and error.

The actual "semantic" part of parsing C++ would still be handled by
Emacs' Semantic package. For instance, it would calculate
completions. So obviously, those completions wouldn't match those from
libclang w.r.t. to accuracy, but they would be *much* better than they
are now, especially because the preprocessor is already handled, which
is currently one of Semantic's main problems. Also, type inference would
already be done by GCC, so you would see the resulting type from 'auto'
and such.

One main problem would be how to parse the file you're currently working
on, since it usually unparseable. I don't have a good answer for
that. We would have our internal parser as fallback, but I would think
that we could also try to internally make the file parseable before
sending it to GCC. It would probably be very messy and involve a lot of
closing braces.

So in a nutshell, for people familiar with clang: my approach is more
like using libtooling/libast than libclang.

All this would have already occupied my spare time for many, many
months, so after this, my plans are very vague. People would probably
want "perfect" completions similar to libclang and not the one by
Semantic. These would have to be provided by GCC itself. Maybe the
'gccsense' patch could serve as a starting point here, but this would
need support from an experienced GCC hacker.

My plan was also to make this plugin usable for other tools. That means,
it should not only output LISP structures, but alternatively also JSON
and possibly XML. For instance, an external tool could build a symbol
database for providing references. This could also serve as a starting
point for doing refactoring. For more complicated tasks, the plugin
could provide an AST matcher which you can query with certain
expressions.

My plan was also to investigate how much work it would be to serve the
AST for other frontends, like Fortran, Go, Java and Ada. I think this
would be the prime advantage over libclang, which is restricted to the
C-family. I haven't looked into it, but I would think that it shouldn't
be too difficult.

-David