On Wed, Sep 14, 2016 at 5:49 AM, Mark Wielaard <m...@redhat.com> 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 <m...@redhat.com> 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?

Reply via email to