PR 40989: Fix Wimplicit

[Gabriel Dos Reis]

On Sat, May 1, 2010 at 3:14 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 1 May 2010 17:05, Gabriel Dos Reis <dosreis@gmail.com> wrote:
>> On Sat, May 1, 2010 at 7:47 AM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>> The problem here is that group options (options that enable other
>>> options) are not handled correctly when enabled by -Werror=. The
>>> following patch fixes this issue for Wimplicit but also adds the
>>> infrastructure to fix it for all other options. When
>>> enabling/disabling an option, we should always use the new
>>> process_option function.
>>>
>>> In the future, we should be able to generate the calls to
>>> process_option automatically from the .opt files.
>>>
>>> Bootstrapped and regression tested on x86_64-linux-gnu. OK?
>>
>> -Wimplicit actually does not make sense for C++, so C++ should not
>> be named here (and I guess ObjC++ by extension.)
>
> Sure.
>
>> It seems to me that this is warning is valid only for the C-family language.
>> Rename 'lang_mask' to 'c_family_mask' or 'c_family_lang_mask'.
>
> Ok.
>
>> the addition of the name 'process_option' to 'handle_option' is a bit confusing.
>> I would suggest to rename process_option to broadcast_user_option.
>
> broadcast sounds a bit strange. I think process_option should be named
> handle_option because it is the parent of all the language-specific
> and target-specific handle_option functions.
>
> The current handle_option reads an option from the command line (from
> argv), so I would rename it to read_cmdline_option. This change is
> very minor, because this function is only used in opts.c and called
> only once.
>
> In summary, the new function for handling an option in general would
> be handle_option, whereas the function for reading an option from the
> command line would be read_cmdline_option. What do you think about
> this?

agreed.

>
> Cheers,
>
> Manuel.
>