On Wed, Sep 14, 2016 at 5:49 AM, Mark Wielaard <[email protected]> wrote: > On Wed, 2016-09-14 at 05:39 -0700, Ian Lance Taylor wrote: >> On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard <[email protected]> wrote: >> > On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote: >> >> I wonder about spelling the options as >> >> -Wshadow={local,compatible-local} rather than with a dash, but >> >> otherwise the patch looks fine. >> > >> > That is a much nicer way to write the option. But if I do that I would >> > like to keep the old names as aliases because Google already ships a gcc >> > that accepts -Wshadow-local and -Wshadow-compatible-local and you can >> > find programs that already probe for those names in their configure >> > scripts. Can I make the existing names hidden aliases by marking them >> > Undocumented in the .opt file? Or is that too contrived/ugly? >> >> I don't have any opinion as to what the option names should be, but I >> don't see the fact that Google's GCC has different option names as a >> concern. That GCC is only used within Google > > Google did release a gcc with those warning options (I believe as part > of the NDK) and there are various projects out there (firefox seems one > of them) that check to see if these options are available before > enabling/disabling them (I don't know if other compilers implemented > them). Given that there are public sources out there that already seem > to use/test for these option names I would prefer to keep the > compatibility.
Thanks again for working on this. I have been using these new options (locally patched) to good effect. While the vast majority of warning-triggering code has been technically correct, using these has uncovered at least 4 or 5 real bugs in code I care about. I see that these new options are not yet on master. Is there anything I can do to help get this patch accepted?
