On Fri, Jan 4, 2013 at 10:43 PM, Eric Christopher <[email protected]>wrote:
> > > > On Fri, Jan 4, 2013 at 10:29 PM, Chandler Carruth <[email protected]>wrote: > >> On Fri, Jan 4, 2013 at 10:23 PM, Eric Christopher <[email protected]>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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
