GitLab

Workaround for random failure of pytest capture on Windows

pytest can capture test output both globally (controlled by the cmd line
flag --capture) or locally (`capsys` and `capfd` fixtures). Enabling both
methods at the same time causes problems on Windows: test output is not
captured sometimes, resulting in test failure. This happens seemingly at
random.

This workaround disables global output capture ("-s", i.e. "--capture=no")
leaving only the local capture fixtures. As a side-effect test output on
AppVeyor CI is a little messy, but this will have to do until a better
solution is found.

Port test suite to pytest

Most of the test code is left in C++ since this is the
intended use case for the eval functions.

Test compilation instructions for Windows were changed to use the
`cmake --build` command line invocation which should be easier than
manually setting up using the CMake GUI and Visual Studio.

Pytest is a development dependency but we can make it painless by
automating the install using CMake.

There are more enum tests than 'constants and functions'.

The C++ part of the test code is modified to achieve this. As a result,
this kind of test:

```python
with capture:
    kw_func1(5, y=10)
assert capture == "kw_func(x=5, y=10)"
```

can be replaced with a simple:

`assert kw_func1(5, y=10) == "x=5, y=10"`

Use simple asserts and pytest's powerful introspection to make testing
simpler. This merges the old .py/.ref file pairs into simple .py files
where the expected values are right next to the code being tested.

This commit does not touch the C++ part of the code and replicates the
Python tests exactly like the old .ref-file-based approach.

Support keep_alive where nurse may be None

Build docs just once, in a dedicated build

For example keep_alive<0,1>() should work where the return value may sometimes be None. At present a "Could not allocate weak reference!" exception is thrown.
Update documentation to clarify behaviour of keep_alive when nurse is None or does not support weak references.

Rather than adding an `if [ -n "$DOCS" ]` as a separate install
instruction, this simplifies the travis-ci logic to do the pip/venv
setup in the `before_install` hook, leaving the install hook to just
install the needed packages.

This makes the default install script simpler: it doesn't need to check
NATIVE_DEPS or DOCS because both of those now override `install`
anyway, so the top-level `install` is really just the install for the
gcc-4.8 and osx builds; the docker builds and docs build override
install completely.

This switches the travis-ci build to build the docs in a dedicated
build rather than as part of the regular linux/osx builds.

Build sphinx docs (with -W) during travis-ci builds

Fix sphinx doc missing code blocks and warnings

The missing empty line after `.. code-block::` resulted in incorrectly
parsed restructuredtext (sphinx warnings) and the code blocks were not
generated in the html output.

The `exclude_patterns` change just silences the orphaned file warning.

[ci skip]

Decay types before passing to is_pod_struct<> / npy_format_descriptor<>

Report warnings as errors on Travis and AppVeyor (-Werror)

Add g++-6 builds to travis-ci

Fix format descriptors for string types

The current linux/g++ testing (using a backported g++-4.8 on a
4-year-old Ubuntu) is quite ancient.  It's good as a baseline level of
support, but it means we aren't testing g++'s C++14 support at all
(which is why #334 happened).

This commit adds a docker-based travis-ci build using the debian
"testing" distribution, which will give us both another test system
(with different versions of build tools), while, more importantly, also
adding a build and test run using g++ in C++14 mode.

This is required since format descriptors for string types that
were using PYBIND11_DESCR were causing problems on C++14 on Linux.

Although this is technically a breaking change, it shouldn't cause
problems since the only use of format strings is passing them to
buffer_info constructor which expects std::string.

Note: for non-structured types, the const char * value is still
accessible via ::value for compatibility purpose.

Add handle::repr() method