1. Aug 30, 2016
    • Wenzel Jakob's avatar
      Merge pull request #374 from jagerman/tpl-tramp-resolution-fix · c50bd5cb
      Wenzel Jakob authored
      Fix template trampoline overload lookup failure
      c50bd5cb
    • Jason Rhinelander's avatar
      Fix template trampoline overload lookup failure · 20978263
      Jason Rhinelander authored
      Problem
      =======
      
      The template trampoline pattern documented in PR #322 has a problem with
      virtual method overloads in intermediate classes in the inheritance
      chain between the trampoline class and the base class.
      
      For example, consider the following inheritance structure, where `B` is
      the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
      intermediate class adding A's methods into the trampoline:
      
          PyB<B> -> PyA<B> -> B -> A
      
      Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
      it to overload the virtual `A::some_method()`.  If a Python class `C` is
      defined that inherits from the pybind11-registered `B` and tries to
      provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
      in PyA<B> fails to find this overloaded method, and thus never invoke it
      (or, if pure virtual and not overridden in PyB<B>, raises an exception).
      
      This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
      simply calls `get_overload(this, name)`; `get_overload()` then uses the
      inferred type of `this` to do a type lookup in `registered_types_cpp`.
      This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
      neither the base type (`B`) nor the trampoline type (`PyB<B>`).  As a
      result, the overload fails and we get a failed overload lookup.
      
      The fix
      =======
      
      The fix is relatively simple: we can cast `this` passed to
      `get_overload()` to a `const B *`, which lets get_overload look up the
      correct class.  Since trampoline classes should be derived from `B`
      classes anyway, this cast should be perfectly safe.
      
      This does require adding the class name as an argument to the
      PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
      unchanged.
      20978263
    • Wenzel Jakob's avatar
      Merge pull request #371 from jagerman/overload-name-doc-fix · d9b3db3e
      Wenzel Jakob authored
      Doc fix for OVERLOAD*_NAME macros
      d9b3db3e
    • Jason Rhinelander's avatar
      Doc fix for OVERLOAD*_NAME macros · 64830e33
      Jason Rhinelander authored
      The documentation says the string-valued python function name goes
      after the C++ function, but it actually goes before it.
      64830e33
    • Wenzel Jakob's avatar
      Merge pull request #369 from jagerman/check-for-tabs · 7946715d
      Wenzel Jakob authored
      Check for style issues during docs build
      7946715d
    • Wenzel Jakob's avatar
      Merge pull request #370 from jagerman/contributing-test-target · 5d1d380e
      Wenzel Jakob authored
      Minor doc fix: ``make test`` -> ``make pytest``
      5d1d380e
  2. Aug 29, 2016
  3. Aug 28, 2016
  4. Aug 27, 2016
  5. Aug 26, 2016
  6. Aug 25, 2016
  7. Aug 23, 2016
    • Wenzel Jakob's avatar
      Merge pull request #351 from dean0x7d/fix-win-test-capture · b692896f
      Wenzel Jakob authored
      Workaround for random failure of pytest capture on Windows
      b692896f
    • Dean Moldovan's avatar
      Workaround for random failure of pytest capture on Windows · b6ccdc95
      Dean Moldovan authored
      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.
      b6ccdc95
  8. Aug 22, 2016