> On Feb 25, 2015, at 11:58 AM, John McCall <[email protected]> wrote:
>
>> On Feb 25, 2015, at 8:14 AM, Ben Langmuir <[email protected]> wrote:
>>> On Feb 24, 2015, at 2:30 PM, John McCall <[email protected]> wrote:
>>>
>>>> On Feb 24, 2015, at 11:14 AM, Ben Langmuir <[email protected]> wrote:
>>>> Hi John,
>>>>
>>>> As we discussed:
>>>>
>>>> Allow (Object *)kMyGlobalCFObj casts without bridging
>>>>
>>>> Previously we allowed these casts only for constants declared in system
>>>> headers, which we assume are retain/release-neutral. Now also allow them
>>>> for constants in user headers, treating them as +0. Practically, this
>>>> means that we will now allow:
>>>> id x = (id)kMyGlobalConst;
>>>>
>>>> But unlike with system headers we cannot mix them with +1 values:
>>>> id y = (id)(b ? kMyGlobalConst : [Obj newValAtPlusOne]); // error
>>>> id z = (id)(b ? kSystemGlobalConst: [Obj newValAtPlusOne]); // OK
>>>>
>>>> <extern-global-const-unbridged-cast.patch>
>>>
>>> Yes, this good great, thank you.
>>>
>>> You should also adjust the ARC specification:
>>
>> Updated patch attached with the spec updates.
>>
>>>
>>> 1. Add "a load from a const non-system global variable of C retainable
>>> pointer type” to the list of known unretained expressions in the section
>>> entitled "Conversion to retainable object pointer type of expressions
>>> with known semantics”. This should have a “beginning LLVM 3.6” note;
>>> when it’s available in a released Apple compiler, we can be more specific.
>>
>> Note the “of C retainable…” bit is part of the context for this list of
>> bullets. I stole the “beginning LLVM 3.6” revision syntax from elsewhere,
>> so hopefully I got it right. I’m having a bit of trouble with sphinx, but
>> I’ll be sure to check the generated doc before I commit.
>>
>>> 2. Add a note to the rationale explaining the different treatment of
>>> system and non-system globals: basically, that it’s reasonable to assume
>>> that global constants were initialized with true constants (e.g. string
>>> literals), but user constants might have been initialized with something
>>> dynamically allocated, using a global initializer.
>>
>
> I’m not going to manually verify the ReST syntax, but the text looks great,
> thanks.
Thanks! r230534
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
