[PATCH] D48241: [DebugInfo] Emit ObjC methods as part of interface.

[Pavel Labath via Phabricator via cfe-commits]

labath added a comment.

I also don't want to get involved too much, but here are my 2c: :)

In https://reviews.llvm.org/D48241#1134342, @JDevlieghere wrote:

> Putting it in a separate column is also a bad idea, because that means the column is present for all the entries, including the ones that don't need it.


This is not true. (Unlike the .apple_*** tables, ) .debug_names allows you to specify a different schema for every entry in the acelerator table. The schema is specifing using abbreviations in much the same way as .debug_abbrev specifies the schema for .debug_info. So you could easily have one abbreviation for regular classes, and a different one for objc interfaces. Currently, our .debug_names generator does not support these kinds of heterogeneous tables, but that's simply because I had no use for it. It could be added if necessary (though it will require some generalization/refactoring). OTOH, our consumer should already be able to handle these kinds of tables as input.

That said, I like this approach more than the putting that information in the accel table. :)



================
Comment at: clang/test/CodeGenObjC/debug-info-category.m:35-37
+// DWARF5: !DISubprogram(name: "-[Foo integer]", scope: ![[STRUCT]], {{.*}}isDefinition: false
+// DWARF5: !DISubprogram(name: "-[Foo integer:]", scope: ![[STRUCT]], {{.*}}isDefinition: false
+// DWARF5: !DISubprogram(name: "-[Foo(Bar) add:]", scope: ![[STRUCT]], {{.*}}isDefinition: false
----------------
Would it make sense to remove the interface part from the method name. When these were freestanding, they were necessary as they were the only link between the method and the interface, but now they are kind of redundant.

This is just an idea, I have no idea what kinds of havoc it will cause for existing consumers, but it seems to me it would make the objc methods more consistent with regular c++ methods.


https://reviews.llvm.org/D48241