higher-performance wrote: > THOUGH: that makes me wonder, have you played with virtual bases yet? Are we > 'sane' for those?
I have not, but those can't be aggregates, right? > The function should be pretty easy though > `// DFS for bases, but it doesn't seem worth the effort to work much harder > to make sure we do the 'shallowest' field, which, while better diagnostics, > is comparatively rare.` Your comment is exactly hinting at why I said this is neither easy, nor efficient. Notice that the fields might not be directly inside the class at all. They might be embedded in some deep (even anonymous) subitem of array of anonymous union of subobject of some far-away base. Digging them up is nowhere as trivial as in your example, **and** it requires traversing a potentially *very* expansive object tree. You could easily traverse 1,000+ fields (possibly inside precompiled modules/headers) to dig up 1 name. That seems... not great? If you're happy with digging up the field name only in a few simple cases (like if it's a direct member of the class or a direct member of one of its direct bases) then sure it's as trivial as your code suggests, and we could do that, but that wouldn't cover everything. https://github.com/llvm/llvm-project/pull/102040 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
