> 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 <[email protected]> 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 > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
