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

[Eric Christopher]

I agree, which is why I was more inclined to think of ways to describe
individual language features to the debugger rather than a massive set
of language specific flags in the compile units :)

-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
>