[cfe-commits] r161362 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaExpr.cpp lib/Sema/SemaExprMember.cpp test/SemaObjC/warn-direct-ivar-access.m

[jahanian]

On Aug 7, 2012, at 10:46 AM, Douglas Gregor wrote:

> 
> On Aug 7, 2012, at 9:43 AM, jahanian <fjahanian at apple.com> wrote:
> 
>> 
>> On Aug 6, 2012, at 5:42 PM, Jordan Rose wrote:
>> 
>>> 
>>> On Aug 6, 2012, at 17:37 , Fariborz Jahanian <fjahanian at apple.com> wrote:
>>> 
>>>> 
>>>> On Aug 6, 2012, at 5:09 PM, Jordan Rose wrote:
>>>> 
>>>>> Why does this only warn under non-GC?
>>>> 
>>>> I don't know. This is an old GCC option and brought it over as-is to clang. I don't have the original gcc radar
>>>> to look for the rational. Could be that under GC it is safe to do direct assignment while with the advent of
>>>> properties, users warn to catch such accesses and use the property syntax which controls the ivar
>>>> access with its own APIs (think atomic vs non-atomic).
>>> 
>>> The same is true under ARC, though. If this is a safety warning, it only really needs to be on for MRC and __unsafe_unretained ivars. I think it's more often a consistency thing, though: if you want Key-Value Observing to work right you have to use the properties.
>>> 
>>> As a heuristic, people often access ivars directly in -init methods and in -dealloc, since properties may be overridden by subclasses. If we were going to split the difference on the warnings, it could be on by default everywhere except -init and -dealloc methods.
>> 
>> My intention was to closely follow gcc's behavior wrt -Wdirect-ivar-access.
> 
> There's no point in modeling GCC 4.2's behavior, because it isn't relevant for Objective-C. Wdirect-ivar-access is intended to warn about direct access to ivars in places where one should probably have accessed a property instead. That has nothing to do with GC or ARC, so the warning should not dependent on the (absence of) those features.
> 

These points are all covered. We don't care about GC. MRR is covered with this patch. ARC already has tight control on how direct assignment/reference to
ivars are warned against. We can open up this option for ARC if there are unsafe cases which is not already covered outside this option. But then, ARC's warnings
are always on by default, this option is not.

- fariborz

> 	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120807/425ab15e/attachment.html>