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

[Joshua Cranmer]

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.
> 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.
>
> +/// 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 :-(

-- 
Joshua Cranmer
News submodule owner
DXR coauthor