[LLVMdev] [RFC] unused argument warning

[Chad Rosier]

On Aug 7, 2012, at 3:14 PM, Daniel Dunbar wrote:

> 
> On Aug 7, 2012, at 3:08 PM, Eli Friedman wrote:
> 
>> On Tue, Aug 7, 2012 at 2:59 PM, Chad Rosier <mcrosier at apple.com> wrote:
>>> All,
>>> I would like to propose a fairly significant change to the unused argument warning (i.e., removing it for the most part), but wanted to get some feedback before investing a great deal of time.  In my opinion, the implementation of this warning is overly burdensome to maintain.  Worse yet, there are _many_ cases where the driver intentionally claims unused arguments to prevent this warning from being too verbose (e.g., clang -E -g t.c -o t.i); when linking the driver claims all CompileOnly arguments.  We should only be warning in cases where it would actually cause a problem (i.e., misspelled options or specifying options that conflict).  Conflicting options _should_ already be handled.  Detecting unknown or misspelled options is very straight forward to implement which doesn't require claim() calls to be sprinkled throughout the driver.
>>> 
>>> Mostly I'm looking for counter arguments as to why this warning should remain given the heavy burden..
>> 
>> The thing I'm most concerned about is that there are arguments which
>> are "known", but don't actually make sense for the current target.  I
>> don't want clang to accept a flag on Darwin just because it's
>> something we forward to the linker on FreeBSD.  The unused argument
>> warning is the only warning which can catch this at the moment.
> 
> In cases where we can easily detect a bad argument situation, I believe part of Chad's proposal should be that we implement specific warnings for those cases. Among other things, this greatly increases the QOI of those warnings.
> 
> The "option-for-non-active-target" diagnostic seems like one we definitely would want to implement (and should be straightforward using option groups I think.

Daniel's beat me to the punchline…  

We need handle these easily detectable cases before we can even consider removing the current implementation.  Yes, option groups seems most reasonable..

> 
> - Daniel
> 
>> 
>> -Eli
>