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

Dimitris Papavasiliou dpapavas@gmail.com
Thu Mar 13 09:52:00 GMT 2014


Ping!

On 03/06/2014 07:44 PM, Dimitris Papavasiliou wrote:
> Ping!
>
> On 02/27/2014 11:44 AM, Dimitris Papavasiliou wrote:
>> Ping!
>>
>> On 02/20/2014 12:11 PM, Dimitris Papavasiliou wrote:
>>> 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
>>>>
>>>
>>
>



More information about the Gcc-patches mailing list