[cfe-dev] A plugin proposal for clang

[Joshua Cranmer]

This is a document in partial response to Douglas Gregor's recent 
comment about needing someone to push forward a plugin proposal for clang.

What kinds of use cases would people have for a compiler plugin?

  * Add a static analyzer
  * Production of ancillary metadata for types and declarations (e.g.,
    adding reflective capabilities to C/C++)
  * Custom optimization passes

The current architecture appears to assume that clang plugins and clang 
itself are primarily useful for static analysis and not for production. 
If I wish to use a plugin, I have to use:
clang -cc1 -load /path/to/plugin.so -plugin Foo -plugin-arg-Foo Bar

But if I'm trying to drop in this plugin in a regular build, I need to do:
clang -Xclang -load -Xclang /path/to/plugin.so -Xclang -add-plugin 
-Xclang Foo -Xclang -plugin-arg-Foo -Xclang Bar

By comparison, a gcc plugin lets me do:
gcc   -fplugin=/path/to/plugin.so -fplugin-arg-plugin-bar=baz

The key things that gcc lets me do in a plugin that I think are 
necessary for clang are to be able to define custom attributes and 
pragmas, which are largely necessary for custom static analysis scripts: 
for example, Mozilla defines several attributes to allow checking of 
properties in their gcc plugins (e.g., enforcing outparameter 
guidelines). All of its other features appear to be either an artifact 
of its code design (e.g., GC interactions) or features that are already 
supported (e.g., adding a new optimization pass).

Another thing which I think is necessary is a macro for the version of 
clang being built, so that plugins can support multiple versions of 
clang at the compiler level (supporting multiple versions in binary form 
is inadvisable, I think).

With that background, here is my rough proposal for plugins; there are 
other changes that I think many plugin writers might like to see, but 
I'll hold off on them, since they don't inhibit writing useful plugins:
1. Add in -fplugin= and -fplugin-arg-<plugin> options for the compiler 
driver. All of the plugins in the library would be loaded and run as if 
specified with -add-plugin (in other words, clang still compiles the code).
2. Add examples of plugins that illustrate iterating over the AST and 
getting IR for functions for futher passes.
3. Ensure existence of support in clang for custom attributes.
4. No guaranteed of API or ABI compatibility between different versions 
of clang; the onus is on the plugin to figure out how to support 
multiple versions. Note that this implies that a version macro is needed 
to report the version of clang/llvm that the plugin is being compiled for.


Thoughts/questions/comments/concerns?

-- 
Joshua Cranmer
News submodule owner
DXR coauthor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111014/47d5fe13/attachment.html>