* Fix warning that not including a cmake source or build dir will be a fatal error (it is now on newest CMakes)
    * Fixes appveyor
* Travis uses CMake 3.9 for more than a year now
* Travis dropped sudo: false in December
* Dropping Sphinx 2
- clang7: Suppress self-assign warnings; fix missing virtual dtors
- pypy:
  - Keep old version (newer stuff breaks)
  - Pin packages to extra index for speed
- travis:
  - Make docker explicit; remove docker if not needed
  - Make commands more verbose (for debugging / repro)
  - Make Ubuntu dist explicit per job
- Fix Windows
- Add names to travis

Cf. https://docs.pytest.org/en/latest/deprecations.html#pytest-namespace

This avoids GIL deadlocking when pybind11 tries to acquire the GIL in a thread that already acquired it using standard Python API (e.g. when running from a Python thread).

[ci skip]

* Adds std::deque to the types supported by list_caster in stl.h.
* Adds a new test_deque test in test_stl.{py,cpp}.
* Updates the documentation to include std::deque as a default
  supported type.

* Add possible solution to ImportError issue

* Check default holder

-Recognize "std::unique_ptr<T, D>" as a default holder even if "D" doesn't match between base and derived holders

* Add test for unique_ptr<T, D> change

Pybind11 provides a cast operator between opaque void* pointers on the
C++ side and capsules on the Python side. The py::cast<void *>
expression was not aware of this possibility and incorrectly triggered a
compile-time assertion ("Unable to cast type to reference: value is
local to type caster") that is now fixed.

* Support C++17 aligned new statement

This patch makes pybind11 aware of nonstandard alignment requirements in
bound types and passes on this information to C++17 aligned 'new'
operator. Pre-C++17, the behavior is unchanged.

This PR brings the std::array<> caster in sync with the other STL type
casters: to accept an arbitrary sequence as input (rather than a list,
which is too restrictive).

Add a detailed link to Python 3 documentation.  Add a caveat about
the program terminating if initializing the interpreter fails.

* Issue #1532: Incompatible config options, /MP vs /Gm for MSVC in DEBUG

* Fix for Issue #1258

list_caster::load method will now check for a Python string and prevent its automatic conversion to a list.
This should fix the issue "pybind11/stl.h converts string to vector<string> #1258" (https://github.com/pybind/pybind11/issues/1258)

* Added tests for fix of issue #1258

* Changelog: stl string auto-conversion

* Update iostream.h: Changed a local varname 'self' to 'self_'

Avoiding conflicts in namespace pybind11::self.
https://github.com/pybind/pybind11/issues/1531

* Fix potential crash when calling an overloaded function

The crash would occur if:
- dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions)
- the first pass (with conversions disabled) doesn't find any matching overload
- the second pass does find a matching overload, but its return value can't be converted to Python

The code for formatting the error message assumed `it` still pointed to the selected overload,
but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass
call returns a nullptr `handle`. Add a new test that segfaults without this fix.

* Make overload iteration const-correct so we don't have to iterate again on second-pass error

* Change test_error_after_conversions dependencies to local classes/variables

* Info about inconsistent detection of Python version between pybind11 and CMake in FAQ

This commit addresses an inefficiency in how enums are created in
pybind11. Most of the enum_<> implementation is completely generic --
however, being a template class, it ended up instantiating vast amounts
of essentially identical code in larger projects with many enums.

This commit introduces a generic non-templated helper class that is
compatible with any kind of enumeration. enum_ then becomes a thin
wrapper around this new class.

The new enum_<> API is designed to be 100% compatible with the old one.

object_api::operator[] has a powerful overload for py::handle that can
accept slices, tuples (for NumPy), etc.

Lists, sequences, and tuples provide their own specialized operator[],
which unfortunately disables this functionality. This is accidental, and
the purpose of this commit is to re-enable the more general behavior.

This commit is tangentially related to the previous one in that it makes
py::handle/py::object et al. behave more like their Python counterparts.