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

Sean Silva silvas at purdue.edu
Wed Aug 1 19:27:06 PDT 2012


This looks like a good step forward w.r.t. the plugin interface.

One problem I see is that for maximal portability, it is probably best
for the plugin function `clang_plugin_on_tu` should take no arguments
and return just a pointer (so its basically a factory function). This
reduces the surface area for ABI problems. Also, there are some places
where you are passing std::string between clang and the plugin, which
is thorny from an ABI standpoint.

However, the biggest problem that I see is that the plugin mechanism
is still really tangled with the rest of Clang. For example, the code
is still iterating over each plugin at the point of extensibility
(rather than encapsulating that in e.g. a PluginManager.cpp), and
CompilerInstance is still being exposed to the whole plugin-loading
mumbo-jumbo. I consider the following to be a hard requirement for the
new plugin API:

Points of extensibility occur in a coherent, unobtrusive,
easily-documented way that makes it easy to extend other classes to
provide plugin capabilities and insulates those classes from
implementation knowledge of the plugin mechanism.

--Sean Silva

2012/7/27 Joshua Cranmer <pidgeot18 at gmail.com>:
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



More information about the cfe-commits mailing list