On Apr 28, 2014, at 3:35 AM, Dimitris Papavasiliou <[email protected]> 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...
