On Jul 27, 2012, at 4:27 PM, Jordan Rose wrote:

> 
> On Jul 27, 2012, at 16:23 , jahanian <[email protected]> wrote:
> 
>> 
>> On Jul 27, 2012, at 3:49 PM, Jordan Rose wrote:
>> 
>>> Hm. Here's that whole function (before the change):
>>> 
>>> ACCResult checkCallToFunction(FunctionDecl *fn) {
>>>   // Require a CF*Ref return type.
>>>   if (!isCFType(fn->getResultType()))
>>>     return ACC_invalid;
>>> 
>>>   if (!isAnyRetainable(TargetClass))
>>>     return ACC_invalid;
>>> 
>>>   // Honor an explicit 'not retained' attribute.
>>>   if (fn->hasAttr<CFReturnsNotRetainedAttr>())
>>>     return ACC_plusZero;
>>> 
>>>   // Honor an explicit 'retained' attribute, except that for
>>>   // now we're not going to permit implicit handling of +1 results,
>>>   // because it's a bit frightening.
>>>   if (fn->hasAttr<CFReturnsRetainedAttr>())
>>>     return ACC_invalid; // ACC_plusOne if we start accepting this
>>> 
>>>   // Recognize this specific builtin function, which is used by CFSTR.
>>>   unsigned builtinID = fn->getBuiltinID();
>>>   if (builtinID == Builtin::BI__builtin___CFStringMakeConstantString)
>>>     return ACC_bottom;
>>> 
>>>   // Otherwise, don't do anything implicit with an unaudited function.
>>>   if (!fn->hasAttr<CFAuditedTransferAttr>())
>>>     return ACC_invalid;
>>> 
>>>   // Otherwise, it's +0 unless it follows the create convention.
>>>   if (ento::coreFoundation::followsCreateRule(fn))
>>>     return ACC_invalid; // ACC_plusOne if we start accepting this
>>> 
>>>   return ACC_plusZero;
>>> }
>>> 
>>> I wonder if leaving the "followsCreateRule" after the CFAuditedTransferAttr 
>>> check would be better; relying on the naming convention for un-audited code 
>>> may be a bad idea even
>> 
>> If I leave it after, then CFAuditedTransferAttr check would not get me to 
>> check for the naming convention. Note that since in the non-diagnose case 
>> they both return
>> ACC_invalid, this will not change the behavior.
> 
> That's intentional. In our real headers, we have CFAuditedTransferAttrs on 
> all parts of CoreFoundation that are guaranteed to correctly follow the 
> naming conventions. CFDictionary.h, for example, is now bracketed in 
> _Pragma("clang arc_cf_code_audited begin") / _Pragma("clang 
> arc_cf_code_audited end"), which implicitly adds the attribute to everything 
> in between. We should probably have this in our fixit test cases.

OK, good to know.
- fariborz

> 
> Jordan

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to