<div class="gmail_quote">On Thu, Jun 28, 2012 at 8:13 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jun 26, 2012, at 1:25 PM, Joshua Cranmer wrote:<br>
<br>
> +def fperplugin_arg : Joined<"-fplugin-arg-">, Group<f_Group>, Flags<[CC1Option]>,<br>
> +  HelpText<"Pass an argument to a plugin">, MetaVarName<"<plugin>-<name>[=<value>]">;<br>
<br>
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.<br></blockquote><div><br></div><div>This should be named fplugin_arg_ -- see the comment at the top of Options.td for how these names are generated.</div>
<div><br></div><div>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?</div><div><br></div><div>We should issue a diagnostic if the plugin name doesn't match any known name (ideally with typo-correction).</div>
<div><br></div><div>GCC's plugin API tells the plugin what its name is (for use in diagnostics etc). Might it make sense to do the same?</div><div><br></div><div><div>+/// Helper macro to call a given function in a plugin:</div>
<div>+/// CALL_PLUGIN_FUNCTION(plugin, clang_plugin_some_func, (arg1, arg2))</div><div>+#define CALL_PLUGIN_FUNCTION(plugin, fname, Args) \</div><div>+  do { \</div><div>+    Plugin::fname Func_ = (Plugin::fname)(plugin)->getFunctionCall(#fname); \</div>
<div>+    if (Func_) \</div><div>+      Func_ Args; \</div><div>+  } while (0)</div><div>+</div><div>+  // These typedefs must have the same signatures as the ones in</div><div>+  // clang/Basic/Plugin.h, including the same name (it makes the helper macro</div>
<div>+  // above work properly).</div></div><div><div>+  typedef void (*clang_plugin_begin_file)(StringRef, const CompilerInstance &,</div><div>+                                          plugin::PluginFileCallbacks &);</div>
<div>+  typedef void (*clang_plugin_end_file)();</div><div>+  typedef void (*clang_plugin_destroy)();</div></div><div><br></div><div>Maybe you could add a PluginAPI.def x-macro for these, and generate Plugin member functions to perform the getAddressOfSymbol + call from that?</div>
</div>