[PATCH] Implement a sane plugin API for clang
pidgeot18 at gmail.com
Wed Mar 13 21:30:55 PDT 2013
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
News submodule owner
More information about the cfe-commits