On Mon, Jul 16, 2012 at 5:27 PM, Richard Smith <rich...@metafoo.co.uk>wrote:
> On Mon, Jul 16, 2012 at 5:15 PM, Jordan Rose <jordan_r...@apple.com>wrote:
>
>>
>> On Jul 16, 2012, at 17:06 , Richard Smith <richard-l...@metafoo.co.uk>
>> wrote:
>>
>> int test6() {
>> int x; // expected-note{{initialize the variable 'x' to silence this
>> warning}}
>> - x += 2; // expected-warning{{variable 'x' is uninitialized when used
>> here}}
>> - return x;
>> + x += 2;
>> + return x; // expected-warning{{variable 'x' is uninitialized when used
>> here}}
>> }
>>
>>
>> Sorry for not chiming in pre-commit, but I'm not happy with this. The
>> first non-compound-assignment use of a variable could be very far from the
>> variable, and while we do get a note on the decl, it still seems like a QoI
>> problem. I'd rather have compound assignments treated as a use *and* an
>> initialization.
>>
>> (Actually, can we just call it a use? Does that hurt anything?)
>>
>
> I mentioned this on the review thread: it introduced "false" positives
> into my test corpus (FSVO "false"). Basically, if a variable is only ever
> used in compound-assignments, but its value is never actually used, we have
> not proven that there is a "real" problem with the code (FSVO "real").
>
> I don't see how the distance between the variable and the use which we
> report is a problem, since we give diagnostics pointing at both of them. I
> would prefer to not add this extra checking (which seems to basically be
> all noise) into -Wuninitialized, but if you feel strongly about this, I'll
> make the change.
>
While using your condition for triggering the warning at all, could we
attach the warning to the 'x += 2', and note the final use? Or at least
note the 'x += 2'? That would seem to address most of Jordan's QoI concern
w/o increasing false positives.
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
