On Jun 22, 2012, at 10:17 AM, Jordan Rose <[email protected]> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to