[cfe-commits] [PATCH] Implement a better plugin API for clang, v3

[Sean Silva]

> I've already tacitly decided that most plugin-compiler interaction should happen via the callbacks interface unless otherwise impractical

I agree. The model that I presented complies with this (albeit with
factory functions instead of a callbacks struct). My description
should have focused more on what I think is the important part of what
I said, which is to make all these points of extensibility occur in a
coherent, easily documented way that makes it easy to extend other
classes to provide plugin capabilities and insulates them from
implementation knowledge of the plugin mechanism (e.g. iterating over
each plugin).

--Sean Silva

On Tue, Jul 17, 2012 at 9:06 AM, Joshua Cranmer <pidgeot18 at gmail.com> wrote:
> On 7/17/2012 1:10 AM, Sean Silva wrote:
>>
>> Correct me if I'm wrong about this, but to my understanding, adding
>> virtual methods (at the end, and with a stub implementation) of an
>> interface class is API/ABI stable (also, just ran into this
>> <http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++>,
>> which seems to agree). Regardless, the design that I'm about to sketch
>> out can be done with an "ops struct" as well. I'll describe it in
>> terms of virtual functions though.
>>
>> The design is the following:
>> Each class inside clang that wants to export callbacks available to
>> plugins (and I guess other clients) can have a FooCallbacks object,
>> similar to how PPCallbacks works now (including how the "chaining" is
>> done). This gives a uniform and clear point of extensibility for
>> making new things available to plugins.
>
> An unfortunate side effect of my current patch is that it gives the
> impression that plugins only do passive observation of the compilation,
> because my first choice of methods are limited to callbacks of the AST,
> preprocessor, and diagnostics. Things like custom attributes, pragmas,
> adding custom preprocessor handling, extra LLVM passes, etc. don't fit as
> well into this mode. Some of these I feel work better in a more declarative
> manner (kind of like the tablegen language). For example, under the current
> architecture of the monolithic PluginCallbacks struct, adding the plugin
> hook for custom attributes involved adding it to the struct and then adding
> to CompilerInstance:
>
> +  for (SmallVector<Plugin, 4>::iterator it = Plugins.begin();
> +       it != Plugins.end(); ++it)
> +    if (it->getCallbacks().getCustomAttributes)
> + TheSema->AddAttributeHandlers(it->getCallbacks().getCustomAttributes());
>
> (plus some modification of Sema's attribute handling code to actually
> support the notion of custom attributes). I've already tacitly decided that
> most plugin-compiler interaction should happen via the callbacks interface
> unless otherwise impractical; killing either the end_file or the destroy
> hook is also a good idea, since the two are (under the current driver model)
> pretty much the same callback.
>
>
> --
> Joshua Cranmer
> News submodule owner
> DXR coauthor
>