Issues with incomplete type from C library

[nilsfriess]

I'm currently trying to write Python bindings for a C++ Library that uses PETSc. Here's a very basic example that demonstrates the issue I have

#include <pybind11/pybind11.h>

#include <petsc.h>

int getSize(Mat mat) {
  int size;
  MatGetLocalSize(mat, &size, nullptr);
  return size;
}

PYBIND11_MODULE(example, m) {
    m.def("getSize", &getSize);
}

When I'm trying to compile this I get a compile error, the important part is at the end of this part:

In file included from /usr/include/c++/13.2.1/bits/stl_pair.h:60,
                 from /usr/include/c++/13.2.1/bits/stl_algobase.h:64,
                 from /usr/include/c++/13.2.1/bits/specfun.h:43,
                 from /usr/include/c++/13.2.1/cmath:3699,
                 from /usr/include/c++/13.2.1/math.h:36,
                 from /usr/include/python3.11/pyport.h:218,
                 from /usr/include/python3.11/Python.h:38,
                 from /home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/detail/common.h:266,
                 from /home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/attr.h:13,
                 from /home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/detail/class.h:12,
                 from /home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/pybind11.h:13,
                 from /home/nils/Projects/pybindpetsc/main.cc:1:
/usr/include/c++/13.2.1/type_traits: In instantiation of ‘struct std::is_base_of<pybind11::detail::pyobject_tag, _p_Mat>’:
/home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/cast.h:1441:76:   recursively required by substitution of ‘template<class T> class pybind11::detail::type_caster<T, typename std::enable_if<std::is_base_of<pybind11::detail::pyobject_tag, typename std::remove_reference<_Tp>::type>::value, void>::type> [with T = _p_Mat]’
/home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/cast.h:1441:76:   required from ‘constexpr const auto pybind11::detail::argument_loader<_p_Mat*>::arg_names’
/home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/cast.h:1441:27:   required from ‘class pybind11::detail::argument_loader<_p_Mat*>’
/home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/pybind11.h:220:43:   required from ‘void pybind11::cpp_function::initialize(Func&&, Return (*)(Args ...), const Extra& ...) [with Func = int (*&)(_p_Mat*); Return = int; Args = {_p_Mat*}; Extra = {pybind11::name, pybind11::scope, pybind11::sibling}]’
/home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/pybind11.h:93:19:   required from ‘pybind11::cpp_function::cpp_function(Return (*)(Args ...), const Extra& ...) [with Return = int; Args = {_p_Mat*}; Extra = {pybind11::name, pybind11::scope, pybind11::sibling}]’
/home/nils/Projects/pybindpetsc/extern/pybind11/include/pybind11/pybind11.h:1170:22:   required from ‘pybind11::module_& pybind11::module_::def(const char*, Func&&, const Extra& ...) [with Func = int (*)(_p_Mat*); Extra = {}]’
/home/nils/Projects/pybindpetsc/main.cc:12:10:   required from here
/usr/include/c++/13.2.1/type_traits:1411:38: error: invalid use of incomplete type ‘struct _p_Mat’
 1411 |     : public integral_constant<bool, __is_base_of(_Base, _Derived)>
In file included from /home/nils/Projects/petsc/include/petscdm.h:5,
                 from /home/nils/Projects/petsc/include/petscdmda.h:3,
                 from /home/nils/Projects/petsc/include/petsc.h:15,
                 from /home/nils/Projects/pybindpetsc/main.cc:3:
/home/nils/Projects/petsc/include/petscmat.h:22:16: note: forward declaration of ‘struct _p_Mat’
   22 | typedef struct _p_Mat *Mat;

The problem is that Mat is a typedef of a forward declaration.

Is there any way to still make this work?

[RyanPorter]

Did you find a workaround for this problem? I'm migrating a rather large project from Boost::Python to pybind11 bindings. The difficulty in working with incomplete types is really the only remaining sticking point for me. I've got about 50 free functions that each rely on one or more incomplete types. The ideas here (#2770) all seem unworkable for one reason or another. Thanks for any insight.