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

[Joshua Cranmer]

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