This patch moves ParseChildArrayInfo out of DWARFASTParserClang in order to decouple Clang-specific logic from DWARFASTParser.
Why we are including just these specific attributes? Maybe we should add a comment explaining it. According to the DWARF standard, any attribute is eligible for any tag.
I think breaking it out of the Clang-specific class makes sense if we want LLDB to be more language-agnostic. Do you have an idea of what bits of DWARFASTParserClang can be moved out other than ParseChildArrayInfo and GetAccessTypeFromDWARF (from the patch on top of this)? What is your end-goal with this decoupling? I assume you want to work towards supporting languages non-clang-based languages but I'm curious about the motivation.
This file will need a license header.
I'm not sure why. Possibly they were added to make sure the switch was fully covered (potentially to silence a warning)? You could add a FIXME or a TODO if you feel that these attributes should have functionality associated with them like the ones above.
Yes, my bad. Thanks for noticing it.
I don't think it is to mark it as fully covered since there are much more attributes, the default label will address it anyway, and according to the DWARF standard, any attribute can be in a type tag (realistically, any tag). We can take the example of DW_AT_description which is just a description associated with the symbol. I feel like this can be safely deleted but I'm afraid to do it in favour of some other rationale I'm not seeing.
@clayborg it looks like this has been this way since you put this in: https://github.com/llvm/llvm-project/commit/261ac3f4b5b98d02dd8718078015a92cf07df736
Do you agree this is dead code or is there something we are missing?
@bulbazord Yes, my plan is to make LLDB interfaces more language-agnostic, to accommodate D programming language DWARFASTParser and TypeSystem. I've seen other language plugins such as Go that simply copy and paste this method, but I want to make D addition clearer and avoid such duplication. You can see more similar changes on Clang-specific code decoupling on the stacked changes.
I have made the requested changes, can you re-review, please? Also pinging @shafik .
Sorry for leaving this hanging for a long time. Feel free to leave feedback if I'm missing something, in the meantime.
I'll try to push the other patches too. I ran the test suite again and didn't break anything.