[PATCH] Implement a sane plugin API for clang

[Joshua Cranmer]

On 3/13/2013 10:05 PM, Sean Silva wrote:
> While I'm all for the idea of improving the plugin API, I think that a 
> modest reduction in boilerplate is not sufficiently compelling to 
> foist a new plugin API on people who already have existing code. The 
> funny thing about boilerplate is that it's easy to copy-paste, so it 
> doesn't really impede people from achieving their goals since they can 
> just copy the code that already works. The primary problem of 
> boilerplate is that it has the effect of deterring newbies, and that 
> issue can be easily combated with improved documentation, which avoids 
> breaking every external plugin and tutorial on plugins.

One thing that REALLY sucks with the current approach is the need to 
specify clang -Xclang -load -Xclang <plugin tarball> -Xclang -add-plugin 
<plugin name> -Xclang -plugin-<name>-arg -Xclang <blah> ...
With the new approach, the command line is clang -fplugin=<tarball> 
-fplugin-arg-<name>-<arg>=<blah>, which is a much shorter command line 
and can actually be passed into CFLAGS/CXXFLAGS without driving libtool 
bonkers (I detest the need for wrapper scripts just to pass arguments) 
and also eliminates warnings whenever people use $(CXX) $(CXXFLAGS) as 
the linker. The present crappy command lines really make plugins feel 
like second-class citizens to Clang.

The changes in this patch retain almost all of the same functionality as 
the original plugin approach (including the ability to do things like 
add custom compile passes via the RegisterPass statics) while wrapping 
it in a much saner wrapper.

> We really ought to have a preliminary discussion on cfe-dev to map out 
> the directions we want to take the plugin API, and what *compelling*, 
> *enabling* changes we can make to it.

I have often heard that the static analyzer in Clang should be remodeled 
as a plugin instead of its current approach, but I'm not exactly sure 
what it was meant by that.

Some changes I have personally wanted to be able to do with plugins 
include the ability to add custom attribute handlers (using annotate("") 
for extra attributes is a very gross hack), as well as be able to 
manipulate the pass manager, to make it easier to test custom 
optimization or analysis patches--this would even imply, in the long 
run, the ability to add custom passes at LTO time. Modelling as plugins 
would greatly reduce barriers for other out-of-tree projects that use 
LLVM and Clang.

> Among other things, I think that we should explicitly look at at 
> multiple plugins "in the wild" and if possible get feedback from as 
> many plugin authors as possible (preferably, plugin authors that are 
> not also "clang developers"). Also, we should ask plugin authors what 
> functionality, if any, they think needs to be added to the plugin API 
> and what were the biggest difficulties they ran into when developing 
> the plugin.
>
> Also, I think the issue of plugin compatibility (both from a technical 
> and "policy" standpoint) needs to be rehashed since it has been a 
> while since it was discussed.
>
> -- Sean Silva


-- 
Joshua Cranmer
News submodule owner
DXR coauthor