Several issues relating to PDB VTables

[trumank]

Version and Platform (required):

• Binary Ninja Version: 5.3.8818-dev, 5e360485
• OS: arch
• OS Version: unknown
• CPU Architecture: x86_64

Bug Description:
I don't where the boundaries between these individual issues lie so here are just my observations trying to get VTables to work:

Test binaries/sources: pdb-vtable.zip

VTables structs are defined without `::` separator which breaks inheritence and references from owning type (fixed in #7825)

With the above patch applied, vtable data refs in linear view still do not show structured data until manually redefined

With the types manually redefined as the same type (Change Type... Enter) inherited members still do not appear

Seems like System Types and Debug Info has diverged?

Virtual function calls do not resolve in HLIL

Parent class gets conflated with namespace and causes VTable name to contain entire class hierarchy

class Level0 {
public:
    int level0_data;

    Level0() : level0_data(0) {}
    virtual ~Level0() { g_sink = 200; }
    virtual void level0Func() { g_sink = 201; }
};

class Level1 : public Level0 {
public:
    int level1_data;

    Level1() : level1_data(1) {}
    ~Level1() override { g_sink = 210; }
    void level0Func() override { g_sink = 211; }
    virtual void level1Func() { g_sink = 212; }
};

class Level2 : public Level1 {
public:
    int level2_data;

    Level2() : level2_data(2) {}
    ~Level2() override { g_sink = 220; }
    void level0Func() override { g_sink = 221; }
    void level1Func() override { g_sink = 222; }
    virtual void level2Func() { g_sink = 223; }
};

[emesare]

Most of this is related to qualified names, we plan on removing it (replaced with a single string) because it causes issues like this. The reason the type shows up when you manually redefine the vtable is because qualified names do not round trip.

>>> current_data_var.type.name.name
['Base', 'VTable']
>>> # Redefine the type via UI
>>> current_data_var.type.name.name
['Base::VTable']

[emesare]

Test 13 has presumably multiple defs at the data var, where the int32_t vtable type is dangling.