[cfe-commits] r171604 - /cfe/trunk/test/CodeGenCXX/debug-info-method.cpp

[David Blaikie]

On Fri, Jan 4, 2013 at 10:49 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Fri, Jan 4, 2013 at 10:43 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>>
>>
>>
>>
>> On Fri, Jan 4, 2013 at 10:29 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>>
>>> On Fri, Jan 4, 2013 at 10:23 PM, Eric Christopher <echristo at gmail.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> > Any ideas how we can make these types of debug info tests
>>>>> > more understandable to future devs? My only idea is copious comments,
>>>>> > but I
>>>>> > feel like having some self-documenting system would be better and I
>>>>> > just
>>>>> > don't have any good ideas about what it would look like.
>>>>>
>>>>> Yeah, I'm not sure what it would look like - essentially the test
>>>>> would have to reference constants from LLVM to describe the flags
>>>>> combined into the flags field. (&, better than that, the ability to
>>>>> specify just some part of the flags value that is of interest to a
>>>>> particular test)
>>>>>
>>>>> Probably just adding comments of the form:
>>>>>
>>>>> ; test that the flags represent the 'protected' access modifier
>>>>> ; 258 (flags) = 42 (thing1) | 157 (thing2) | (protected) 8
>>>>>
>>>>> (I haven't actually looked up what constants are combined into the
>>>>> flags value in this case)
>>>>
>>>>
>>>> That would work, an option for more self-documentation would be to have
>>>> the
>>>> debug output (e.g. [ DW_TAG_class_type ]) contain the access specifiers.
>>>
>>>
>>> Just brain storming: what about having the IR asm printer show the sorted
>>> |'ed set of flags in a comment?
>>>
>>
>>
>> Well, yeah, that's what I was saying :)
>
>
> Yay overloaded meaning of 'debug'. I thought you meant make the debug info
> flags actually symbolic like some of the other things... But yea, it reads
> better the other way.

It's not a categorical fix across all flags, etc, but I've addressed
this issue in r171636 (LLVM improvement to include '[protected]' or
'[private]' for subprogram debug info metadata in the same way we
already included this for member debug info metadata) and r171637
(modifying the Clang test to check for this data rather than the field
value itself).

- David