[PING^2][PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope

[Dimitris Papavasiliou]

Hello all,

Pinging this patch review request again.  See previous messages quoted 
below for details.

Regards,
Dimitris

On 02/13/2014 04:22 PM, Dimitris Papavasiliou wrote:
> Hello,
>
> Pinging this patch review request. Can someone involved in the
> Objective-C language frontend have a quick look at the description of
> the proposed features and tell me if it'd be ok to have them in the
> trunk so I can go ahead and create proper patches?
>
> Thanks,
> Dimitris
>
> On 02/06/2014 11:25 AM, Dimitris Papavasiliou wrote:
>> Hello,
>>
>> This is a patch regarding a couple of Objective-C related dialect
>> options and warning switches. I have already submitted it a while ago
>> but gave up after pinging a couple of times. I am now informed that
>> should have kept pinging until I got someone's attention so I'm
>> resending it.
>>
>> The patch is now against an old revision and as I stated originally it's
>> probably not in a state that can be adopted as is. I'm sending it as is
>> so that the implemented features can be assesed in terms of their
>> usefulness and if they're welcome I'd be happy to make any necessary
>> changes to bring it up-to-date, split it into smaller patches, add
>> test-cases and anything else that is deemed necessary.
>>
>> Here's the relevant text from my initial message:
>>
>> Two of these switches are related to a feature request I submitted a
>> while ago, Bug 56044
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044). I won't reproduce
>> the entire argument here since it is available in the feature request.
>> The relevant functionality in the patch comes in the form of two
>> switches:
>>
>> -Wshadow-ivars which controls the "local declaration of ‘somevar’ hides
>> instance variable" warning which curiously is enabled by default instead
>> of being controlled at least by -Wshadow. The patch changes it so that
>> this warning can be enabled and disabled specifically through
>> -Wshadow-ivars as well as with all other shadowing-related warnings
>> through -Wshadow.
>>
>> The reason for the extra switch is that, while searching through the
>> Internet for a solution to this problem I have found out that other
>> people are inconvenienced by this particular warning as well so it might
>> be useful to be able to turn it off while keeping all the other
>> shadowing-related warnings enabled.
>>
>> -flocal-ivars which when true, as it is by default, treats instance
>> variables as having local scope. If false (-fno-local-ivars) instance
>> variables must always be referred to as self->ivarname and references of
>> ivarname resolve to the local or global scope as usual.
>>
>> I've also taken the opportunity of adding another switch unrelated to
>> the above but related to instance variables:
>>
>> -fivar-visibility which can be set to either private, protected (the
>> default), public and package. This sets the default instance variable
>> visibility which normally is implicitly protected. My use-case for it is
>> basically to be able to set it to public and thus effectively disable
>> this visibility mechanism altogether which I find no use for and
>> therefore have to circumvent. I'm not sure if anyone else feels the same
>> way towards this but I figured it was worth a try.
>>
>> I'm attaching a preliminary patch against the current revision in case
>> anyone wants to have a look. The changes are very small and any blatant
>> mistakes should be immediately obvious. I have to admit to having
>> virtually no knowledge of the internals of GCC but I have tried to keep
>> in line with formatting guidelines and general style as well as looking
>> up the particulars of the way options are handled in the available
>> documentation to avoid blind copy-pasting. I have also tried to test the
>> functionality both in my own (relatively large, or at least not too
>> small) project and with small test programs and everything works as
>> expected. Finallly, I tried running the tests too but these fail to
>> complete both in the patched and unpatched version, possibly due to the
>> way I've configured GCC.
>>
>> Dimitris
>