[PATCH]: Add a flag to the DWARF Compile Unit to indicate if it was compiled with ARC

[Adrian Prantl]

On May 13, 2013, at 2:57 PM, Eric Christopher <echristo at gmail.com> wrote:

> On Mon, May 13, 2013 at 2:35 PM, John McCall <rjmccall at apple.com> wrote:
>> On May 13, 2013, at 1:44 PM, Eric Christopher <echristo at gmail.com> wrote:
>>> On Mon, May 13, 2013 at 1:25 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>>> 
>>>> On May 13, 2013, at 11:57 AM, Eric Christopher <echristo at gmail.com> wrote:
>>>> 
>>>>> Eh? Curious what this will be used for?
>>>> This would be interesting mostly for the debugger but I guess tools like Instruments would also like to know.
>>> 
>>> In what way? I.e. why add it?
>> 
>> It's a language mode, Eric.  It's smaller in scope than C++ but on approximately the same scope as OpenCL.  Users have a reasonable expectation that source-aware tools like debuggers and profilers will know what language the source code is written in.
>> 
> 
> I'm perfectly aware of what ARC is and you'll notice I mentioned other
> options earlier. One of the current accepted dwarf issues is adding
> OpenCL to the language list. Whether or not this is worth adding a new
> language enum entry was one thing I had specifically brought up.
> 
>> Off-hand, here are some ways that a tool might take advantage of knowing that it's analyzing an ARC program:
>>  - it could enable better support for printing weak variables
>>  - it could automatically use appropriate semantics for assigning into weak or strong variables with an expression
>>  - it could correctly handle ARC-specific language constructs in the expression evaluator
>>  - it could take it as a general license to intercept the ARC runtime calls
>>  - it could monitor retain/release events and advise the user when a retain cycle was formed or broken
>> 
> 
> Sure. While most of this can be trivially handled by attributes on
> variables and looking at the program perhaps a language enum addition
> is the best way if it's such a different language. After all we have
> c89 and c99 to help deal with different default semantics there, but
> no C++11 because that was handled by general types and attributes. If
> we want to handle a bunch of arc features I'm asking these questions
> to figure out the best way to support them long term.


With ObjC++, there would be two additional languages, not just one. Since you mentioned the long term: If we treat it as a new language, how will we handle similar language modes in the future? I want to avoid polluting the languages enum with all permutations of ObjC(xx)FeatureX, ObjC(xx)ArcAndFeatureX, etc -- that would be ugly ;-)

-- adrian