Handle __declspec(novtable)

[sei-eschwartz]

In #275, we learned that certain ATL interface classes use __declspec(novtable) which stops the compiler from installing vftables. This causes problems with reasonNOTConstructor_G, and probably other rules as well.

This can be observed in https://github.com/edmcman/MFCApplication/blob/master/Release/MFCApplication.exe at CView::CView which does not install a vftable.

How should we fix this? One option might be to hard-code a list of classes to block for reasonNOTConstructor_G. For example, in #275, that would be CScrollView. CScrollView does have a vftable, but its parent, CView, does not. We can use RTTI to identify the installation of CScrollView's vftable, and from there block it.

But this only works because CScrollView does not have __declspec(novtable). It definitely could though, as it is an abstract class. So this technique might not work universally.

[sei-eschwartz]

Another option could be using hashes like for new and delete. I doubt these functions change much.

[sei-eschwartz]

Cory suggested adding a noVFTableClassConstructor/1 fact that can introduce synthetic vftable writes and initial memory, such as:

possibleVFTableWrite(0x4f7de6, 0x4f7de3, sv_18361059439791859340, 0, 0xeeeeee)
initialMemory(0xeeeeee, 0x53af32) 

[sei-eschwartz]

Some code thrown around chat:

factVFTableWrite(Addr, Addr, ThisPtr, VFTable) :-
    noVFTableClassConstructor(Addr),
    thisPtrDefinition(ThisPtr, _, _, 0, Addr),
    VFTable = vftable-hack-thing(Addr).
initalMemory(VFTable, PureAddr):
    noVFTableClassConstructor(Addr),
    thisPtrDefinition(ThisPtr, _, _, 0, Addr),
    factVFTableWrite(Addr, Addr, ThisPtr, VFTable)
    purecall(PureAddr).