<div dir="ltr">On Thu, Mar 14, 2013 at 12:30 AM, Joshua Cranmer <span dir="ltr"><<a href="mailto:pidgeot18@gmail.com" target="_blank">pidgeot18@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 3/13/2013 10:05 PM, Sean Silva wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>

</blockquote>
<br></div>
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> ...<br>

With the new approach, the command line is clang -fplugin=<tarball> -fplugin-arg-<name>-<arg>=<<u></u>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.</blockquote>
<div><br></div><div><div><br class="">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.</div>
<div> </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The present crappy command lines really make plugins feel like second-class citizens to Clang.<br>

<br></blockquote><div><br></div><div style>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.</div><div style><br></div><div style>
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.</div><div style><br></div><div style>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.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<div class="im">
<br></div></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="">
<div class="h5"><br></div></div></blockquote></div><br></div><div class="gmail_extra" style>These are all excellent ideas. Please start a new thread so that we can have a focused discussion about these and other ideas.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>-- Sean Silva</div></div>