On Thu, Jun 28, 2012 at 8:13 PM, Jordan Rose <[email protected]> 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?
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
