[Bug objc/56044] New: Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[Bug objc/56044] New: Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

             Bug #: 56044
           Summary: Add dialect option to gobjc to prevent instance
                    variables from posing as local variables inside
                    methods.
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: objc
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dpapavas@gmail.com


Class instance variables in Objective-C can be accessed as if they were local
variables (without self->) inside class methods which luckily can be avoided
simply by not using the feature.  The only problem is that in that case you're
prevented from using an actual local variable or method argument with the same
name.  This can often be useful for instance in cases such as these:

-(SomeOmbject *)initWithBuffer: (char *buffer)
{
    [super init];
    self->buffer = buffer;

    return self;
}

In this case the compile would warn about variable shadowing and to avoid that
you have to find some other name for the variable which can get annoying.  It
would be nice therefore if this feature could be disabled for those that do not
like to use it.

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-19 20:07:30 UTC ---
Did you try -Wshadow ?

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-01-19
     Ever Confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-19 20:08:45 UTC ---
Also do you have a self contained testcase for this?

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #3 from Dimitris Papavasiliou <dpapavas at gmail dot com> 2013-01-19 22:27:30 UTC ---
Created attachment 29224
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29224
Testcase

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #4 from Dimitris Papavasiliou <dpapavas at gmail dot com> 2013-01-19 22:29:10 UTC ---
I have considered -Wshadow and this is the way I think I'll go for now because
thinking up of variable names is hard enough without having to think of
synonyms on top.  The problems with -Wshadow are that:

 1) It also disables other warnings about variable shadowing which are pretty
useful and

 2) It doesn't solve the opposite side of the problem: If you decide not to use
this instance-var-as-auto convention then if for some reason, say due to a
typo, you do use it inadvertently the compiler will not complain but silently
do something you didn't mean to do.

(BTW while researching this in hope of finding something like the requested
switch, I've found numerous other complaints and questions along the same lines
so it seems it would be useful to others as well).

Testcase attached.  Just use it with

  gcc -c autoivar.m 

Let me know if there's anything more I can do to help.

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #5 from Dimitris Papavasiliou <dpapavas at gmail dot com> 2013-01-20 11:09:57 UTC ---
Actually trying out -Wno-shadow indicates that it doesn't make any difference
in this case.  The compiler keeps complaining about the instance variable being
hidden by the local one.  If there is another warning option I can use to turn
it off please let me know as I couldn't find it.

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #6 from Dimitris Papavasiliou <dpapavas at gmail dot com> ---
Created attachment 30417
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30417&action=edit
Proposed patch adding switches controlling ivar scope in Objective-C.

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #7 from Dimitris Papavasiliou <dpapavas at gmail dot com> ---
I made a patch for this (as well as some other minor features) and submitted it
to the gcc-patches list but, since it was ignored there I'm also attaching it
here in case someone decides to look at it at some point.

The following is the message I posted in the list with the details of the
patch:

---------

First, let me say that I have consciously broken most of the rules mentioned
about patch submission at gcc.gnu.org but I have done so in order to spare
myself from wasting time to provide a proper patch in case the implemented
functionality is not deemed worthy of approval and adoption into GCC.  If any
of the implemented switches prove to be welcome I'll be more than happy to
split them into separate patches, add test-cases and add ChangLog entries as
needed.

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
>From gcc-bugs-return-425553-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 08:27:24 2013
Return-Path: <gcc-bugs-return-425553-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8439 invoked by alias); 2 Jul 2013 08:27:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8398 invoked by uid 48); 2 Jul 2013 08:27:19 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
Date: Tue, 02 Jul 2013 08:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57749-4-fXB2llxKzx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57749-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57749-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00060.txt.bz2
Content-length: 681

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW749

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The actual code where the original issue occurred had the exponentiation
> in the deep of nested loops, it would have been rather time consuming
> to test base==0
> at the Fortran level

Sorry, but I don't buy the argument. The cost of the test will likely be the
same in gfortran or in the library.

> And I still do not understand why if the exponent is integer no
> exception is raised and
> the expected result zero is delivered.

When the exponent is integer, the computation is done through multiplications
and zero times anything finite is zero.

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #8 from Dimitris Papavasiliou <dpapavas at gmail dot com> ---
Is there anything more I can do to help with this?  Does the process simply
take a lot of time or is there no interest in such a feature?

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
After sending a patch to gcc-patches, please keep pinging weekly on 
gcc-patches with the ObjC maintainers CC:ed, and giving the URL of the 
original patch submission, for as long as it takes (it may help to include 
confirmation that the paperwork described at 
http://gcc.gnu.org/contribute.html has been done, if the change is large 
enough to need it).

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[dpapavas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #10 from Dimitris Papavasiliou <dpapavas at gmail dot com> ---
I see, thanks for the advice.  Just a clarification: you mean that I should CC
the personal email of the two objc maintainers as I find it from the page
below, correct?

http://gcc.gnu.org/svn/gcc/branches/cilkplus/MAINTAINERS

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 5 Feb 2014, dpapavas at gmail dot com wrote:

> I see, thanks for the advice.  Just a clarification: you mean that I should CC
> the personal email of the two objc maintainers as I find it from the page
> below, correct?

Yes - the people listed under "objective-c/c++".  It can be useful to CC 
maintainers on an initial patch submission; definitely do so on patch 
pings if the original submission didn't get a response from the.

[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
Committed revision 209753.