Ralf W. Grosse-Kunstleve 1d81191077 Disable implicit conversion of 0 to pybind11::handle. (#4008) ... * Disable implicit conversion from `0` to `pybind11::handle`. * Reverse or-ed condition in an attempt to resolve GCC 8.3.0 errors (i386/debian:buster). * Trying the simpler `std::is_same<T, PyObject *>` * Add implicit_conversion_from_pytorch_THPObjectPtr_to_handle test. * Accommodate types with implicit conversions to `PyObject *`, other than `handle` & `handle` subclasses, or integral types. * Fix copy-paste mishap (picked wrong name). * Revamp SFINAE construct to actually fix the pytorch issue (already validated against pytorch proper). The first version of the reduced pytorch code was critically missing the move ctor. The first version of the accompanying test was meaningless. Note: It turns out the `!std::is_arithmetic<T>` condition is not needed: `int` is not in general implicitly convertible to `PyObject *`, only the literal `0` is. * Use `NOLINT(performance-noexcept-move-constructor)` for reduced code from the wild (rather than changing the code). * Use any_of, all_of, negation. It turns out to clang-format nicer. * Clean up comments for changed code. * Reduce pytorch situation further, add test for operator ... const. * Use `none_of` as suggested by @skylion007 * Add `pure_compile_tests_for_handle_from_PyObject_pointers()` * Fix inconsequential oversight (retested). * Factor our `is_pyobj_ptr_or_nullptr_t` to make the SFINAE conditions more readable. * Remove stray line (oversight). * Make the `pure_compile_tests_for_handle_from_PyObject_pointers()` "rhs-const-complete", too. * Remove the temporary PYBIND11_UNDO_PR4008 `#ifdef`.		2022-07-14 09:53:39 -07:00
..
pybind11	Disable implicit conversion of 0 to pybind11::handle. (#4008)	2022-07-14 09:53:39 -07:00