dwblaikie wrote: > The link from the class to the specific vtable even seems mildly incorrect, > in that during object construction the vtable will go through several > different values, not just one.
Not sure I follow this - the object is only of the type, in some sense, when it is pointing to that particular vtable. When the base subobject is constructed - it's only that, the base subobject (Or on destruction - once the most derived destruction has run, and the vtable is set to the base type, all the object is, in some sense, at that point, is the base subobject) Though I haven't thought seriously about the representation - truly off the cuff, take with a grain of salt, etc, the static member that is the vtable seems sort of reasonable to me. Not sure why it'd be necessary to make that vtable global variable "global" rather than static within the class? Is that for debug_names lookup? (I think static members are still in the index, right?) If it's a class member you can still do bidirectional lookup, right? IF you find the variable, you can find its parent to see which class it applies to, and if you have the class you can find the vtable variable inside it? https://github.com/llvm/llvm-project/pull/130255 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
