1. 15 Sep, 2020 1 commit
    • Yannick Jadoul's avatar
      Resolve empty statement warning when using PYBIND11_OVERLOAD_PURE_NAME and... · d65e34d6
      Yannick Jadoul authored
      Resolve empty statement warning when using PYBIND11_OVERLOAD_PURE_NAME and PYBIND11_OVERLOAD_PURE (#2325)
      
      * Wrap PYBIND11_OVERLOAD_NAME and PYBIND11_OVERLOAD_PURE_NAME in do { ... } while (false), and resolve trailing semicolon
      
      * Deprecate PYBIND11_OVERLOAD_* and get_overload in favor of PYBIND11_OVERRIDE_* and get_override
      
      * Correct erroneous usage of 'overload' instead of 'override' in the implementation and internals
      
      * Fix tests to use non-deprecated PYBIND11_OVERRIDE_* macros
      
      * Update docs to use override instead of overload where appropriate, and add warning about deprecated aliases
      
      * Add semicolons to deprecated PYBIND11_OVERLOAD macros to match original behavior
      
      * Remove deprecation of PYBIND11_OVERLOAD_* macros and get_overload
      
      * Add note to changelog and upgrade guide
      d65e34d6
  2. 11 Jan, 2018 1 commit
    • Jason Rhinelander's avatar
      Fix segfault when reloading interpreter with external modules (#1092) · 326deef2
      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).
      326deef2
  3. 23 Dec, 2017 1 commit
    • Jason Rhinelander's avatar
      Silence new MSVC C++17 deprecation warnings · 3be401f2
      Jason Rhinelander authored
      In the latest MSVC in C++17 mode including Eigen causes warnings:
      
          warning C4996: 'std::unary_negate<_Fn>': warning STL4008: std::not1(),
          std::not2(), std::unary_negate, and std::binary_negate are deprecated in
          C++17. They are superseded by std::not_fn(). You can define
          _SILENCE_CXX17_NEGATORS_DEPRECATION_WARNING or
          _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
          received this warning.
      
      This disables 4996 for the Eigen includes.
      
      Catch generates a similar warning for std::uncaught_exception, so
      disable the warning there, too.
      
      In both cases this is temporary; we can (and should) remove the warnings
      disabling once new upstream versions of Eigen and Catch are available
      that address the warning. (The Catch one, in particular, looks to be
      fixed in upstream master, so will probably be fixed in the next (2.0.2)
      release).
      3be401f2
  4. 12 Sep, 2017 1 commit
  5. 24 Jun, 2017 2 commits
  6. 08 Jun, 2017 1 commit
    • Jason Rhinelander's avatar
      Destroy internals if created during Py_Finalize() · 4edb1ce2
      Jason Rhinelander authored
      Py_Finalize could potentially invoke code that calls `get_internals()`,
      which could create a new internals object if one didn't exist.
      `finalize_interpreter()` didn't catch this because it only used the
      pre-finalize interpreter pointer status; if this happens, it results in
      the internals pointer not being properly destroyed with the interpreter,
      which leaks, and also causes a `get_internals()` under a future
      interpreter to return an internals object that is wrong in various ways.
      4edb1ce2
  7. 07 Jun, 2017 1 commit
  8. 28 May, 2017 3 commits