Re: pre-summit introspection status

[Behdad Esfahbod <behdad behdad org>]

Gustavo J. A. M. Carneiro wrote:
> On Fri, 2008-10-10 at 17:19 -0400, Behdad Esfahbod wrote:
>> Colin Walters wrote:
>>> On Thu, Oct 9, 2008 at 9:34 PM, Behdad Esfahbod <behdad behdad org> wrote:
>>>> But most recently I was reading the static analysis literature and came across
>>>> the idea of using gcc user-attributes for source code annotation.  Take the
>>>> above example, then one can define:
>>>>
>>>> #define G_IR_ARRAY __attribute__((user(g_ir_array)))
>>>>
>>>> On the face, it's not much different from what I proposed earlier.  However,
>>>> it has an immense power: you can use gcc or gcc-compatible frontends.
>>> Well, using gcc as a parser is problematic
>>> (http://lwn.net/Articles/301135/).
>> Can't read that right now.  Will try again when it's free.  But Tom Tromey
>> told me that the gcc plugin patch will land soonish.
> 
> Apparently there are also fundamental problems with the way GCC parses
> types, see http://www.gccxml.org/Bug/view.php?id=7572

That's a gccxml bug report, not a gcc one.  It may well be caused by the stage
that gccxml hooks into.  And a weird bug in template instantiation is pretty
much irrelevant to GNOME anyway.

> This kind of problem can cause serious portability issues, for instance.
> Having used GCC-XML extensively in recent months, I am now very wary
> about the possibility of using it in GNOME if the alternative gtk-doc
> parser works.

Note that I did not suggest that.  What I requested was using code, not
comment, annotations, such that people can write static analyzers using
existing frontends.  What the introspection framework continues to use is none
of my business.

>>> Right now we have a custom parser
>>> that generally works.  Not that it doesn't have its limitations but
>> it
>>> would be a lot of work to replace.
>>>
>>>> Moreover, you can write static analyzers that check, for example,
>> that the
>>>> array is not shorter than its claimed length.  The possibilities
>> are uncountable.
>>> Well, one could also modify the static analyzer to understand the
>>> gtk-doc annotations.
>> Right... Writing yet another frontend with it's own bugs and
>> limitations...
>> Between gcc and llvm there's room to accommodate everyone...
> 
> gcc has its own bugs and limitations as well.

It just so happens that gcc is currently able to parse our code, where as any
other compiler/parser stumbles every now and then.


behdad