Re: new plugin events

["Joseph S. Myers" <joseph@codesourcery.com>]

On Fri, 6 Nov 2009, Richard Guenther wrote:

> its internal symbols are to be exported), they reduce the value of
> the FSF GCC version because it lacks features only available as plugin.

That's why I think it's important for people to consider carefully in each 
case whether a plugin or integration in GCC is the right way to implement 
a given feature.  I think of plugins as being for GCC features (warnings, 
optimizations, etc.) only relevant for compiling some piece of software or 
using some library, for example, and not generally relevant to standard 
code in the relevant source language.  They are not generally appropriate 
for optimizations relying only on standard language or library features, 
for example.

There are cases where the expected instability of the plugin API can be a 
*feature*.  For example, people have wanted ways for -Wformat to check 
custom types of format strings, but there's never been a design I've been 
happy with in terms of both sufficient flexibility and not exporting too 
much implementation internals that we might wish to change in future.  I'd 
be much happier there with a few plugin hooks that expose all the format 
checking datastructures, and an understanding that these will change or 
break when those structures change, than with directly exposing all those 
structures to user source code as part of the GNU C and C++ languages.  
(Making the checking for GCC-internal formats into such a plugin has been 
suggested in the past, and is not completely unreasonable.)

-- 
Joseph S. Myers
joseph@codesourcery.com