[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

Douglas Gregor dgregor at apple.com
Tue Aug 7 13:27:21 PDT 2012


On Aug 7, 2012, at 1:01 PM, jahanian <fjahanian at apple.com> wrote:

> 
> On Aug 7, 2012, at 11:03 AM, jahanian wrote:
> 
>> 
>> On Aug 7, 2012, at 10:46 AM, Douglas Gregor wrote:
>>> 
>>> 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.
> 
> Doug,
> 
> Do you think it is worthwhile the effort to include this warning under ARC, turn the warning on by default and then run clang tests through it.
> This gives us some ideas as to usefulness of this option under ARC. If the new warnings are covered by ARC's own warnings, then we can turn it
> back off for ARC.

ARC has an error for weak ivar access; it doesn't cover any of the (more common) cases of ivar access that we still want to warn about with this warning.

So, I still think that we should not turn on/off this warning depending on whether the code is MRR/GC/ARC, because it has nothing to do with the memory model. Of course, if the ARC error for weak ivar access fails, we should not emit the warning, because the error is more important.

	- Doug

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


More information about the cfe-commits mailing list