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

[Eric Christopher]

To be more specific, I'm not against this if that's the only route we
can take, but I want to avoid this sort of thing if we can so I'd
rather spend the up front time to figure out what needs to happen and
how it should be described rather than just add something in real
fast. I'm not happy with some of the other extensions we've got as it
is :)

-eric

On Mon, May 13, 2013 at 3:20 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> 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
>