This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope

On Apr 28, 2014, at 3:35 AM, Dimitris Papavasiliou <> wrote:
>>> +  a = private;    /* { dg-warning "hides instance variable" "" { xfail *-*-* } } */
>>> +  a = protected;  /* { dg-warning "hides instance variable" "" { xfail *-*-* } } */
>>> +  a = public;     /* { dg-warning "hides instance variable" "" { xfail *-*-* } } */
>> No, we don’t expect failures.  We makes the compiler do what we wants or it gets the hose again.  Then, we expect it to be perfect.  If you won’t want warning, and non are produces, then just remove the /* … */, or write /* no warning */.
> I've fixed these as per your request.  For the record though, this form of test seems to be fairly common in the test suites as this output indicates:
> dimitris@debian:~/sandbox/gcc-build$ find ../gcc-source/gcc/testsuite/ -name "*.c" -o -name "*.C" -o -name "*.m" | xargs grep "xfail \*-\*-\*" | wc -l
> 354
> Many of these seem to be in error or warning messages which are expected not to show up.  In any case if the messages do show up they'll trigger the excessive messages test so I suppose that's enough.

>> Once we resolve the 3 warning tests above, this will be ok.
> Actually, there were a few more { xfail *-*-* } in the other test cases.  I've removed these as well.

So, let’s make sure we’re on the same page…

Take shadow-2.m for example, before you said:

+  a = private;    /* { dg-warning "hides instance variable" "" { xfail *-*-* } } */

and now you say:

+  a = private;    /* No warning. */

So, the first question is, what do we _want_ in the end here?  Warning or no warning?  And what do we actually do now, warn or not?

If in the end, we want a warning, then the previous form is the right eventually form.  If we don’t want a warning, then the second is correct, though, there is another form that is not unreasonable:

  i += [Base class_func1];  /* { dg-bogus "invalid receiver type" } */

this says that we used to generate a warning (or an error message), but that was wrong, and we no longer want to expect a warning, and that the bug has been fixed and that no warning is generated.

I think we are on the same page, just wanted to make sure...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]