Omit panics for pure virtual overrides

[rcalixte]

• Closes Panic "can only override virtual methods for directly constructed types" when calling a parent class override method #246

cc @arnetheduck

[mappu]

Awesome work as always - I love the unit tests (and they're probably fine where they are for now).

This turned out to be a really simple patch. I don't think i quite get the mechanism though - is that all there is to it, just skip the ok checks for those methods? Why does that work, why doesn't the ok check pass in the first place?

A Miqt MiqtVirtualQStringListModel only inherits from a QStringListModel > QAbstractListModel > QAbstractItemModel, so when you call QStringListModel.OnColumnCount in Go that hits QAbstractItemModel_override_virtual_columnCount, which only applies the slot update ifff returns ok as well.

And it shouldn't pass the check, since dynamic_cast<MiqtVirtualQAbstractItemModel*> should(?) fail since that's not in the inheritance hierarchy.

So how exactly does skipping the ok check allow that last unit test to pass? 🤔

[rcalixte]

So how exactly does skipping the ok check allow that last unit test to pass? 🤔

My reading of the code is that the failure is due to the dynamic cast failing on the C++ side but like you said, this should be failing for more than just these pure virtual instances. I'll see about testing other instances.

[rcalixte]

So how exactly does skipping the ok check allow that last unit test to pass? 🤔

I'm thinking that the issue is that the derived class re-implementation is private meaning that when the binding doesn't expose the derived methods, the failing dynamic cast is exposed. The override can fail silently while the private derived implementation still correctly runs.

We have another example: QAbstractItemView::setModel. For QListWidget, QTableWidget, and QTreeWidget, this method is private but the base class implementation is virtual. In the bindings though, each inherits from QListView, QTableView, and QTreeView respectively which each has a public override. In C++, calling setModel from the derived classes where it is private is a compilation error. In the bindings, it silently fails.

For our case, I think the inheritance structure is what breaks the virtual dispatch here. I can't find other examples for other types of classes. I'm also not sure how to best design this. Should the failure be swallowed or surfaced? Arguably, the current panic for columnCount coincides with an operation that shouldn't attempt to be implemented by a developer.