[PATCH] Implement a sane plugin API for clang

[Sean Silva]

On Thu, Mar 14, 2013 at 12:30 AM, Joshua Cranmer <pidgeot18 at gmail.com>wrote:

> 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.



Realistically a tiny script might be a better long-term design, allowing
e.g. "clang++ `clang-plugin-config myPlugin.so arg1 arg2` foo.cpp".
Remember that the primary advantage of plugins vs libtooling/libclang is
that they are run as part of a build process, meaning that in reality these
command lines are meant to be generated by a "configure" step and not by
hand. So really the "user friendliness" is determined by "how easy is it to
integrate a clang plugin into my build", and not by the exact commandline
syntax per se. This kind of script could also serve as a useful layer of
indirection and "user friendliness", e.g. it could recognize a
"CLANG_PLUGIN_PATH" or other niceties that would be dubious to add to clang
itself.



> The present crappy command lines really make plugins feel like
> second-class citizens to Clang.
>
>
TBQH it is a second-class citizen if you consider how much development
effort and dogfooding go into it compared to e.g. libtooling or libclang.

Of course, I think it would be great to lift it from this status! But I
think that we need some more discussion and a better sense of direction for
that to happen.

If you really want to immediately push plugins forward in a big way, it
would be monumental to set up a buildbot that runs a clang plugin that does
extra checking that isn't really appropriate for being integrated as a
diagnostic into the compiler proper. For example, a plugin that warns on
incorrect uses of dyn_cast<>. For maximum effect this should be developed
in-tree (probably in clang-tools-extra. Even though it has "tools" in the
name, I don't think anybody would be opposed to developing plugins in
there). It should also have an easy way for people in our community to come
up with and implement good extra checks and get them integrated into that
buildbot.

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.
>
>
My opposition to the current patch is that it does not provide enough value
to our users to compensate for the inconvenience that it will cause them
(by breaking their code). My opposition is not technical; I don't doubt
that your approach here is an improvement from a purely technical
standpoint.


>  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.
>
>
These are all excellent ideas. Please start a new thread so that we can
have a focused discussion about these and other ideas.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130314/597c7ae3/attachment.html>