[PATCH] Allow (Object *)kMyGlobalCFObjc casts without bridging

[Ben Langmuir]

> On Feb 25, 2015, at 8:14 AM, Ben Langmuir <blangmuir at apple.com> wrote:
> 
>> 
>> On Feb 24, 2015, at 2:30 PM, John McCall <rjmccall at apple.com> wrote:
>> 
>>> On Feb 24, 2015, at 11:14 AM, Ben Langmuir <blangmuir at apple.com> 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.

And it looks like I got wrong.  I updated to:

* :when-revised:`[beginning LLVM 3.6]` :revision:`a load from a` ``const``
  :revision:`non-system global variable.`

because there doesn’t seem to be a way to nest the ``literal text`` within the :revision:`interpreted text`.

> 
>> 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.
> 
> 
> Thanks,
> 
> Ben
> 
> <extern-global-const-unbridged-cast-2.patch>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150225/ede15517/attachment.html>