jmorse wrote: > Maybe it's too big/complex a problem to try to think about, and incremental > development should overrule here - but may be worth thinking about?
Urgh. I'll admit that I hadn't thought that far ahead, I just wanted to get the patch-series going again now that the root problem is identified. The DWARF in the existing patch series [0] seems to take a similar direction to this patch, of putting information into declarations where possible. Have a look at the check-lines for llvm/test/DebugInfo/Generic/lexical-block-static-var.ll: the static-local variables are defined and given a location inside DW_TAG_lexical_blocks within the abstract definitions of functions, and then there are some other DW_TAG_lexical_blocks inside the inlined instances. It's not clear to me how the inlined-lexical-blocks refer back to the abstract ones. I don't have a complete understanding of how the entire patch series operates, but types-and-variables-in-declarations appears to be where we're heading. It makes sense for our metadata to reflect this. Given that the ODR-uniquing issue was only found experimentally in-the-field, I think we have to accept the incremental approach and discover problems by experience. Stepping back slightly: I think the ODR-uniquing of these types is directly opposed to scope-precision: reducing the number of type definitions down to one _necessarily_ means discarding the extra locality information about where it's scoped in different function instances. Given that the ODR-uniquing facility already exists, I assume it's not something that can be turned off due to efficiency reasons. Thus we're reduced to workarounds while pushing towards the end-solution. [0] final significant patch https://reviews.llvm.org/D144008 , you have to manually delete the phab-error overlay https://github.com/llvm/llvm-project/pull/119001 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits