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

Richard Smith richard at metafoo.co.uk
Thu Jun 28 20:43:02 PDT 2012


On Thu, Jun 28, 2012 at 8:13 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Jun 26, 2012, at 1:25 PM, Joshua Cranmer wrote:
>
> > +def fperplugin_arg : Joined<"-fplugin-arg-">, Group<f_Group>,
> Flags<[CC1Option]>,
> > +  HelpText<"Pass an argument to a plugin">,
> MetaVarName<"<plugin>-<name>[=<value>]">;
>
> It's really bugging me that the name of the flag doesn't match the typed
> form. I think fplugin_arg is fine, even though there's more to it than that.
>

This should be named fplugin_arg_ -- see the comment at the top of
Options.td for how these names are generated.

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?

We should issue a diagnostic if the plugin name doesn't match any known
name (ideally with typo-correction).

GCC's plugin API tells the plugin what its name is (for use in diagnostics
etc). Might it make sense to do the same?

+/// 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120628/b6f3a258/attachment.html>


More information about the cfe-commits mailing list