Jason Rhinelander 7672292e6b Add informative compilation failure for method_adaptor failures ...

When using `method_adaptor` (usually implicitly via a `cl.def("f",
&D::f)`) a compilation failure results if `f` is actually a method of
an inaccessible base class made public via `using`, such as:

    class B { public: void f() {} };
    class D : private B { public: using B::f; };

pybind deduces `&D::f` as a `B` member function pointer.  Since the base
class is inaccessible, the cast in `method_adaptor` from a base class
member function pointer to derived class member function pointer isn't
valid, and a cast failure results.

This was sort of a regression in 2.2, which introduced `method_adaptor`
to do the expected thing when the base class *is* accessible.  It wasn't
actually something that *worked* in 2.1, though: you wouldn't get a
compile-time failure, but the method was not callable (because the `D *`
couldn't be cast to a `B *` because of the access restriction).  As a
result, you'd simply get a run-time failure if you ever tried to call
the function (this is what #855 fixed).

Thus the change in 2.2 essentially promoted a run-time failure to a
compile-time failure, so isn't really a regression.

This commit simply adds a `static_assert` with an accessible-base-class
check so that, rather than just a cryptic cast failure, you get
something more informative (along with a suggestion for a workaround).

The workaround is to use a lambda, e.g.:

    class Derived : private Base {
    public:
        using Base::f;
    };

    // In binding code:
    //cl.def("f", &Derived::f); // fails: &Derived::f is actually a base
                                // class member function pointer
    cl.def("f", [](Derived &self) { return self.f(); });

This is a bit of a nuissance (especially if there are a bunch of
arguments to forward), but I don't really see another solution.

Fixes #1124

2017-10-12 09:45:07 -04:00

..

pybind11

Add informative compilation failure for method_adaptor failures

2017-10-12 09:45:07 -04:00