<div class="gmail_quote">On Thu, Jul 5, 2012 at 1:05 PM, Joshua Cranmer <span dir="ltr"><<a href="mailto:pidgeot18@gmail.com" target="_blank">pidgeot18@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 6/28/2012 11:43 PM, Richard Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote></div>
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.</blockquote>
<div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
GCC's plugin API tells the plugin what its name is (for use in diagnostics etc). Might it make sense to do the same?<br>
</blockquote></div>
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.</blockquote>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
+/// Helper macro to call a given function in a plugin:<br>
+/// CALL_PLUGIN_FUNCTION(plugin, clang_plugin_some_func, (arg1, arg2))<br>
+#define CALL_PLUGIN_FUNCTION(plugin, fname, Args) \<br>
+  do { \<br>
+    Plugin::fname Func_ = (Plugin::fname)(plugin)-><u></u>getFunctionCall(#fname); \<br>
+    if (Func_) \<br>
+      Func_ Args; \<br>
+  } while (0)<br>
+<br>
+  // These typedefs must have the same signatures as the ones in<br>
+  // clang/Basic/Plugin.h, including the same name (it makes the helper macro<br>
+  // above work properly).<br>
+  typedef void (*clang_plugin_begin_file)(<u></u>StringRef, const CompilerInstance &,<br>
+  plugin::PluginFileCallbacks &);<br>
+  typedef void (*clang_plugin_end_file)();<br>
+  typedef void (*clang_plugin_destroy)();<br>
<br>
Maybe you could add a PluginAPI.def x-macro for these, and generate Plugin member functions to perform the getAddressOfSymbol + call from that?<br>
</blockquote>
<br></div>
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 :-(</blockquote><div><br></div><div>It'd be a little ugly, but something like this might work:</div>
<div><br></div><div>PLUGIN_FUNCTION(begin_file, void, (StringRef Filename, const CompilerInstance &CI, plugin::PluginFileCallbacks &CB), (Filename, CI, CB))</div></div>