On Tue, Nov 19, 2019 at 11:02 PM David Malcolm <dmalc...@redhat.com> wrote: > > > > The checker is implemented as a GCC plugin. > > > > > > The patch kit adds support for "in-tree" plugins i.e. GCC plugins > > > that > > > would live in the GCC source tree and be shipped as part of the GCC > > > tarball, > > > with a new: > > > --enable-plugins=[LIST OF PLUGIN NAMES] > > > configure option, analogous to --enable-languages (the > > > Makefile/configure > > > machinery for handling in-tree GCC plugins is adapted from how we > > > support > > > frontends). > > > > I like that. Implementing this as a plugin surely must help to > > either > > document the GCC plugin interface as powerful/mature for such a > > task. Or > > make it so, if it isn't yet. ;-) > > Our plugin "interface" as such is very broad.
Just to sneak in here I don't like exposing our current plugin "non-API" more. In fact I'd just build the analyzer into GCC with maybe an option to disable its build (in case it is very fat?). >From what I read it seems the analyzer could do with a proper plugin API that just exposes introspection - and I really hope somebody finds the time to complete (or rewrite...) the proposed introspection API that ideally is even cross-compiler (proven by implementing said API ontop of both GCC and clang/llvm). That way the Analyzer would work with both GCC and clang [and golang and rustc...]. So it would be interesting if you could try to sketch the kind of API the Analyzer needs? That is, merely the detail on which it inspects statements, the CFG and the callgraph. Richard.
