[cfe-dev] Clang plugins

[Joshua Cranmer]

Several months ago [1], I proposed a plugin API for clang, but I have 
seen no traction on getting it into the tree. Given the increased 
documentation for plugins (see 
<http://clang.llvm.org/docs/ClangPlugins.html>), I am beginning to feel 
that is urgent to settle on a direction for plugins.

In my opinion, the biggest problem I want to solve with plugins as they 
are now is the need for a cumbersome -Xclang -load -Xclang 
/path/to/plugin.so -Xclang -add-plugin -Xclang <plugin name> syntax and 
to replace it with a more tenable -fplugin=/path/to/plugin.so. Beyond 
that, the other major issue is that the current way plugins are 
specified in the source code feels broken:
1. The PluginASTAction inherits from ASTFrontendAction, but it is never 
used as an ASTFrontendAction if -add-plugin is used. Given that clang is 
now a sufficiently robust compiler, I think the utility of having a 
plugin system that doesn't cause normal processing to occur is rather 
low (you could use -fsyntax-only if you really don't want to do anything 
other than parse the tree and run plugins).
2. The PluginASTAction does not lend itself to adding future hooks that 
do things other than passively watch the parser, such as modifying the 
list of optimization passes or tool invocations.
3. The use of the static registry initializer makes it impossible to 
gate decisions of what to make available.

What are people's opinions on this topic?

[1] See 
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-October/017972.html>, 
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-January/019650.html>, 
<http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120305/054486.html>.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor