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.. Chad
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. -Eli
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> > -Eli