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

[Douglas Gregor]

On Jun 22, 2012, at 10:17 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> Hi, Joshua. First off, I really like that you submitted a /patch/ for a better plugin API, including all the documentation and example changes that would have otherwise been necessary to put into an e-mail. It shows that your proposal is feasible and well-defined already, and gives us something to work with.
> 
>> Why would you need two copies of Basic/Lex/etc.? Clang is already built with all of this stuff, so the plugin would be able to use clang's version of everything here in normal codegen anyways, unless I'm misunderstanding your statement.
> 
> 
> What I meant was that if we wanted to run some action instead of CodeGen, we would need to use libTooling instead...but that means building a separate executable with everything in it again. But I forgot about -fsyntax-only, and plugins could require this in their clang_plugin_begin_file check.
> 
> (It might be nice if they could check this sooner, though...maybe they can get the CompilerInvocation in clang_plugin_init, possibly even as non-const! -fsyntax-only isn't the only interesting setting.)

I think it's completely reasonable for plugins to have the opportunity to look at the CompilerInvocation to figure out whether they can actually run or not. The static analyzer certainly wouldn't want to bother registering itself to run if clang was passed -E. Whether they error or (better) warn in this case would be up to the plugin. 

I wouldn't want plugins to be able to mutate the CompilerInvocation's action, because the driver has expectations on what the clang action is supposed to do. Having -plugin=clang-analyzer.so automatically turn on -fsyntax-only, for example, would be rather surprising to a driver that expects clang to produce a .o file.

> On the flip side, it might be desirable for plugins to be able to produce errors and a nonzero result code. Whether or not these plugin diagnostics can halt CodeGen is something to consider as well.


I think it's reasonable for plugins to produce errors, which should cause a nonzero result code. One could use this, for example, to enforce coding standards with a locally-developed style-checking plugin.

	- Doug