GitLab

[skip ci]

Fixes #1046.

[skip ci]

There are two separate additions:

1. `py::hash(obj)` is equivalent to the Python `hash(obj)`.
2. `.def(hash(py::self))` registers the hash function defined by
   `std::hash<T>` as the Python hash function.

The warning is shown at module initialization time (on import, not
when the functions are called). It's only visible when compiled in
debug mode.

This is analogous to `py::init()` vs `__init__` + placement-new.
`py::pickle()` reuses most of the implementation details of `py::init()`.

The lookup of the `self` type and value pointer are moved out of
template code and into `dispatcher`. This brings down the binary
size of constructors back to the level of the old placement-new
approach. (It also avoids a second lookup for `init_instance`.)

With this implementation, mixing old- and new-style constructors
in the same overload set may result in some runtime overhead for
temporary allocations/deallocations, but this should be fine as
old style constructors are phased out.

[skip ci]

Creating an instance of of a pybind11-bound type caused a reference leak in the
associated Python type object, which could prevent these from being collected
upon interpreter shutdown. This commit fixes that issue for all types that are
defined in a scope (e.g. a module). Unscoped anonymous types (e.g. custom
iterator types) always retain a positive reference count to prevent their
collection.

For the case of `pip install --user`, the header include dirs must
also include `pybind11.get_include(True)`.

[skip appveyor]

The default `install_headers` from `distutils` flattens all the headers
into a single directory -- `detail` subdirectory was lost. This commit
fixes this by overriding the setup with a custom header installer.

Tests are added to Travis to make sure `setup.py sdist` and `pip install`
do not miss any headers and that the directory structure is preserved.

[skip appveyor]

Newer clang produces additional warnings.

[skip appveyor]

The `latest` build remains as is, but all others are modified to:

* Use regular Python instead of conda. `pip install` is much faster
  than conda, but scipy isn't available. Numpy is still tested.

* Compile in debug mode instead of release.

* Skip CMake build tests. For some reason, CMake configuration is very
  slow on AppVeyor and these tests are almost entirely CMake.

The changes reduce build time to about 1/3 of the original. The `latest` 
config still covers scipy, release mode and the CMake build tests, so 
the others don't need to.

The current PYBIND11_INTERNALS_ID depends on the version of the library
in order to isolate binary incompatible internals capsules. However,
this does not preclude conflicts between modules built from different
(binary incompatible) commits with the same version number.

For example, if one module was built with an early v2.2.dev and
submitted to PyPI, it could not be loaded alongside a v2.2.x release
module -- it would segfault because of incompatible internals with
the same ID.

This PR changes the ID to depend on PYBIND11_INTERNALS_VERSION which is
independent of the main library version. It's an integer which should be
incremented whenever a binary incompatible change is made to internals.

PYBIND11_INTERNALS_KIND is also introduced for a similar reason.

The same versioning scheme is also applied to `type_info` and the
`module_local` type attribute.

The "see above" comment being referenced in the code comments isn't
"above" anymore; copy the later factory init comment into the first
constructor block to fix it.

[skip ci]

[skip ci]

Fixes one small variable name typo, and two instances where `py::arg().nocopy()` is used, where I think it should be `py::arg().noconvert()` instead. Probably `nocopy()` was the old/original name for it and then it was changed.

The main point of `py::module_local` is to make the C++ -> Python cast
unique so that returning/casting a C++ instance is well-defined.
Unfortunately it also makes loading unique, but this isn't particularly
desirable: when an instance contains `Type` instance there's no reason
it shouldn't be possible to pass that instance to a bound function
taking a `Type` parameter, even if that function is in another module.

This commit solves the issue by allowing foreign module (and global)
type loaders have a chance to load the value if the local module loader
fails.  The implementation here does this by storing a module-local
loading function in a capsule in the python type, which we can then call
if the local (and possibly global, if the local type is masking a global
type) version doesn't work.