On Tue, 2019-12-03 at 11:52 -0500, David Malcolm wrote: > On Wed, 2019-11-20 at 11:18 +0100, Richard Biener wrote: > > 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?). > > My aim here is to provide a way for distributors to be able to > disable > its build - indeed, for now, for it to be disabled by default, > requiring opting-in. It seems like there's some move to have this as part of the core compiler rather than as a plug-in. That's a bit of a surprise, but a good one.
> I want some way to label the code as a "technology preview", that > people may want to experiment with, but to set expectations that this > is a lot of new code and there will be bugs - but to make it > available > to make it easier for adventurous users to try it out. > > I hope that makes sense. > > I went down the "in-tree plugin" path by seeing the analogy with > frontends, but yes, it would probably be simpler to just build it > into > GCC, guarded with a configure-time variable. It's many thousand > lines > of non-trivial C++ code, and associated selftests and DejaGnu tests. Given the overall feedback, core component with an opt-out seems like it'd be best. jeff >
