[cfe-commits] [PATCH] Implement a better plugin API for clang, v2

[Richard Smith]

On Thu, Jul 5, 2012 at 1:05 PM, Joshua Cranmer <pidgeot18 at gmail.com> wrote:

> On 6/28/2012 11:43 PM, Richard Smith wrote:
>
>> It seems strange to split the key=value part of plugin arguments in the
>> frontend. Why not just let the plugin do that, if it wants the argument
>> split that way?
>>
> I think that key=value pairs are sufficiently common to be worthwhile to
> parse beforehand, since they'll be the form that is used to pass in things
> like auxiliary configuration details, output files, etc.


Pre-split key=value pairs would prevent any plugin from using pre-existing
infrastructure (such as getopt, or LLVM's own CommandLine library) for
handling its command-line arguments, or at least force such plugins to
first try to reconstitute the original arguments first. It's also not clear
to me that a plugin would be able to tell the difference between
'-fplugin-arg-foo-bar' and '-fplugin-arg-foo-bar='. I also don't see that
it provides significant convenience to plugin authors to pre-split the
strings (they just have to switch from strcmp to strncmp).


>  GCC's plugin API tells the plugin what its name is (for use in
>> diagnostics etc). Might it make sense to do the same?
>>
> I don't know how helpful this feature is. On reflection, it strikes me
> that the path of the library file might be useful (so you can load a
> "global" data file which is sited relative to the library or something),
> but I'm not sure it's worth complicating the UI without a use case.


I believe the idea is to allow plugins to give their names in diagnostics
(for instance, to tell the user to specify -fplugin-arg-$PLUGIN-whatever).
Since the 'name' is entirely determined by the .so file's name, the plugin
may not otherwise have a mechanism to know this.


>
>> +/// Helper macro to call a given function in a plugin:
>> +/// CALL_PLUGIN_FUNCTION(plugin, clang_plugin_some_func, (arg1, arg2))
>> +#define CALL_PLUGIN_FUNCTION(plugin, fname, Args) \
>> +  do { \
>> +    Plugin::fname Func_ = (Plugin::fname)(plugin)->**getFunctionCall(#fname);
>> \
>> +    if (Func_) \
>> +      Func_ Args; \
>> +  } while (0)
>> +
>> +  // These typedefs must have the same signatures as the ones in
>> +  // clang/Basic/Plugin.h, including the same name (it makes the helper
>> macro
>> +  // above work properly).
>> +  typedef void (*clang_plugin_begin_file)(**StringRef, const
>> CompilerInstance &,
>> +  plugin::PluginFileCallbacks &);
>> +  typedef void (*clang_plugin_end_file)();
>> +  typedef void (*clang_plugin_destroy)();
>>
>> Maybe you could add a PluginAPI.def x-macro for these, and generate
>> Plugin member functions to perform the getAddressOfSymbol + call from that?
>>
>
> I don't think macros are powerful enough to generate the member functions
> here, since it would need both function argument types and argument names
> :-(


It'd be a little ugly, but something like this might work:

PLUGIN_FUNCTION(begin_file, void, (StringRef Filename, const
CompilerInstance &CI, plugin::PluginFileCallbacks &CB), (Filename, CI, CB))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120705/9663e009/attachment.html>