erichkeane 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?
Right, good, yeah, that shouldn't be a problem then. > > 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. I very much think we need to 'do better'. Upon further reflection, I would think that any amount of depth beyond direct fields is perhaps gilding the lily (and would probably require breadcrumbs), so direct fields is perhaps good enough. That said, the diagnostic was really quite opaque when trying to use it/figure out what I was doing. We need to improve the diagnostics in those cases to make it more clear(at least SOME level of hint) to users of this feature what they are looking for. For simple Fields, we can just print the 1st, for types in fields/more complicated fields, perhaps just point at the field (and mention the type name that causes the problem), and do a similar thing for the base classes. 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
