1. Sep 11, 2018
  2. Apr 29, 2018
  3. Feb 07, 2018
    • Wenzel Jakob's avatar
      mark release date in changelog · f117a48e
      Wenzel Jakob authored
      f117a48e
    • Jason Rhinelander's avatar
      Updated version/changelog for 2.2.2 · 19e90dc3
      Jason Rhinelander authored
      19e90dc3
    • Wenzel Jakob's avatar
      ebe16361
    • Jason Rhinelander's avatar
      MSVC workaround for broken `using detail::_` warning · f99f6851
      Jason Rhinelander authored
      Current MSVC generates totally bizarre errors:
      
          error C2884: 'pybind11::detail::_': introduced by using-declaration
          conflicts with local function 'pybind11::detail::_'
      
      which makes no sense (since the supposed "conflict" is the function
      itself).  Work around it by `using namespace detail;` instead (which
      also lets us drop a bunch of other `detail::` qualifications, so isn't
      actually a bad thing).
      f99f6851
    • Jason Rhinelander's avatar
      Use stricter brace initialization · c3d81d23
      Jason Rhinelander authored
      This updates the `py::init` constructors to only use brace
      initialization for aggregate initiailization if there is no constructor
      with the given arguments.
      
      This, in particular, fixes the regression in #1247 where the presence of
      a `std::initializer_list<T>` constructor started being invoked for
      constructor invocations in 2.2 even when there was a specific
      constructor of the desired type.
      
      The added test case demonstrates: without this change, it fails to
      compile because the `.def(py::init<std::vector<int>>())` constructor
      tries to invoke the `T(std::initializer_list<std::vector<int>>)`
      constructor rather than the `T(std::vector<int>)` constructor.
      
      By only using `new T{...}`-style construction when a `T(...)`
      constructor doesn't exist, we should bypass this by while still allowing
      `py::init<...>` to be used for aggregate type initialization (since such
      types, by definition, don't have a user-declared constructor).
      c3d81d23
    • Jason Rhinelander's avatar
      Don't add duplicate patients · 56c1edb4
      Jason Rhinelander authored
      This fixes #1251 (patient vector grows without bounds) for the 2.2.2
      branch by checking that the vector doesn't already have the given
      patient.
      
      This is a little less elegant than the same fix for `master` (which
      changes the patients `vector` to an `unordered_set`), but that requires
      an internals layout change, which this approach avoids.
      56c1edb4
    • Jason Rhinelander's avatar
      Fix segfault when reloading interpreter with external modules (#1092) · 20d6d1d4
      Jason Rhinelander authored
      * Fix segfault when reloading interpreter with external modules
      
      When embedding the interpreter and loading external modules in that
      embedded interpreter, the external module correctly shares its
      internals_ptr with the one in the embedded interpreter.  When the
      interpreter is shut down, however, only the `internals_ptr` local to
      the embedded code is actually reset to nullptr: the external module
      remains set.
      
      The result is that loading an external pybind11 module, letting the
      interpreter go through a finalize/initialize, then attempting to use
      something in the external module fails because this external module is
      still trying to use the old (destroyed) internals.  This causes
      undefined behaviour (typically a segfault).
      
      This commit fixes it by adding a level of indirection in the internals
      path, converting the local internals variable to `internals **` instead
      of `internals *`.  With this change, we can detect a stale internals
      pointer and reload the internals pointer (either from a capsule or by
      creating a new internals instance).
      
      (No issue number: this was reported on gitter by @henryiii and @aoloe).
      20d6d1d4
    • Jeff VanOss's avatar
      fix return from std::map bindings to __delitem__ (#1229) · 17ad517d
      Jeff VanOss authored
      Fix return from `std::map` bindings to `__delitem__`: we should be returning `void`, not an iterator.
      
      Also adds a test for map item deletion.
      17ad517d