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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to