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