* Add support for nested C++11 exceptions
* Remove wrong include
* Fix if directive
* Fix missing skipif
* Simplify code and try to work around MSVC bug
* Clarify comment
* Further simplify code
* Remove the last extra throw statement
* Qualify auto
* Fix typo
* Add missing return for consistency
* Fix clang-tidy complaint
* Fix python2 stub
* Make clang-tidy happy
* Fix compile error
* Fix python2 function signature
* Extract C++20 utility and backport
* Cleanup code a bit more
* Improve test case
* Consolidate code and fix signature
* Fix typo
* A way to register additional test targets.
* Support specifying tests with extension.
* Ensure TEST_OVERRIDE is backwards compatible.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Ensure regex is non greedy.
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Replacing ICC C++14 with C++17
* ICPC: -diag-disable:conversion
Try to suppress the `-Werror-all` promotion in `#include <variant>`
* Trying `-DPYBIND11_WERROR=OFF`
* Trying `-Wno-conversion` (todo: make specific to C++17 if it works)
* Inserting -Wno-conversion only for C++17
Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
* docs: update changelog
* Update changelog.rst
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Ensure ThreadPool is closed in setup_helpers
The ParallelCompile setup helper using a ThreadPool to enable its
parallelism. It does not properly close the pool when it is done with
it.
This can lead to a "Exception ignored in: <function Pool.__del__..."
message with traceback being printed at shutdown.
Use pool.terminate() instead of context manager for Python 2.7
compatibility
* Add note to remove code that supports Python 2
Co-authored-by: Bobby Impollonia <bobby@k13capital.com>
* fix: vs2022 compilation, issue #3477
* silence warning for python 2.7
* disable warning around mbstowcs call
* move disable warning code closer to call site
* turn on vs2022 ci test
* ci: don't run helpers on Windows 2022 & Python 3.5
* limit workaround for stdlib shipped with vs2022 or later
* fix for: limit workaround for stdlib shipped with vs2022 or later
* fix 2 for: limit workaround for stdlib shipped with vs2022 or later
* comment
* ci: add a Windows 2019 run
* ci: add Python 2.7 check too
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* Expand string_view support to str, bytes, memoryview
1. Allows constructing a str or bytes implicitly from a string_view;
this is essentially a small shortcut allowing a caller to write
`py::bytes{sv}` rather than `py::bytes{sv.data(), sv.size()}`.
2. Allows implicit conversion *to* string_view from py::bytes -- this
saves a fair bit more as currently there is no simple way to get such
a view of the bytes without copying it (or resorting to Python API
calls).
(This is not done for `str` because when the str contains unicode we
have to allocate to a temporary and so there might not be some string
data we can properly view without owning.)
3. Allows `memoryview::from_memory` to accept a string_view. As with
the other from_memory calls, it's entirely your responsibility to
keep it alive.
This also required moving the string_view availability detection into
detail/common.h because this PR needs it in pytypes.h, which is higher
up the include chain than cast.h where it was being detected currently.
* Move string_view include to pytypes.h
* CI-testing a fix for the "ambiguous conversion" issue.
This change is known to fix the `tensorflow::tstring` issue reported under https://github.com/pybind/pybind11/pull/3521#issuecomment-985100965
TODO: Minimal reproducer for the `tensorflow::tstring` issue.
* Make clang-tidy happy (hopefully).
* Adding minimal reproducer for the `tensorflow::tstring` issue.
Error without the enable_if trick:
```
/usr/local/google/home/rwgk/forked/pybind11/tests/test_builtin_casters.cpp:169:16: error: ambiguous conversion for functional-style cast from 'TypeWithBothOperatorStringAndStringView' to 'py::bytes'
return py::bytes(TypeWithBothOperatorStringAndStringView());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/google/home/rwgk/forked/pybind11/include/pybind11/detail/../pytypes.h:1174:5: note: candidate constructor
bytes(const std::string &s) : bytes(s.data(), s.size()) { }
^
/usr/local/google/home/rwgk/forked/pybind11/include/pybind11/detail/../pytypes.h:1191:5: note: candidate constructor
bytes(std::string_view s) : bytes(s.data(), s.size()) { }
^
```
* Adding missing NOLINTNEXTLINE
* Also apply ambiguous conversion workaround to str()
Co-authored-by: Ralf W. Grosse-Kunstleve <rwgk@google.com>
* Replace usage of deprecated Eigen class
Eigen::MappedSparseMatrix has been deprecated since Eigen 3.3 from 2016. Use the equivalent modern syntax Eigen::Map<Eigen::SparseMatrix<...>>.
* Update eigen.h
* Update eigen.h
* fix compiler warning: deprecated implicit copy constructor
* take care of the bug http://eigen.tuxfamily.org/bz/show_bug.cgi?id=747
* add parenthesis for better reading
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update include/pybind11/eigen.h
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* Fix py::kw_only when used before the first arg of a method
The implicit space for the `self` argument isn't added until we hit the
first argument, but this wasn't being done for kw_only or pos_only, and
so a kw_only before the first argument would break.
This fixes it by properly checking whether we need to add the self arg.
(The pos_only issue here was extremely mild -- you didn't get the `/` in
the docstring, but AFAICT it has no other effect since there are no
meaningful arguments before it anyway).
* Style changes
- rename check_have_self_arg -> append_self_arg_if_needed
- move the argument name inline comments before the args instead of
after
* ci: support development releases of Python
* fix: better PyPy support
* fix: patch over a few more pypy issues
* Try to patch
* Properly follow pep667
* Fix typo
* Whoops, 667 not in yet
* For testing
* More testing
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Try to backport
* Try to simplify fix
* Nail down the fix
* Try pypy workaround
* Typo
* one last typo
* Replacing 0x03110000 with 0x030B0000
* Add TODO. Drop PyPy
* Fix typo
* Revert catch upgrade
* fix: minor cleanup, try pypy again
Co-authored-by: Aaron Gokaslan <skylion.aaron@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Ralf W. Grosse-Kunstleve <rwgk@google.com>
* override: Fix wrong caching of the overrides
There was a problem when the python type, which was stored in override
cache for C++ functions, was destroyed and the record wasn't removed from the
override cache. Therefor, dangling pointer was stored there. Then when the
memory was reused and new type was allocated at the given address and the
method with the same name (as previously stored in the cache) was actually
overridden in python, it would wrongly find it in the override cache for C++
functions and therefor override from python wouldn't be called.
The fix is to erase the type from the override cache when the type is destroyed.
* test: Pass by const ref instead of by value (clang-tidy)
* test: Rename classes and move to different files
Rename the classes and files so they're no too generic. Also, better place to
test the stuff is in test_virtual_functions.cpp/.py as we're basically testing
the virtual functions/trampolines.
* Add TODO for erasure code
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* docs: rework CI a bit, more modern skipping
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
On Unix, setuptools prepends $CFLAGS and $CPPFLAGS to the compiler flags
(they always come before extra_compile_args and anything else; see
distutils.sysconfig.customize_compiler). In practice, the environment
variables are useful e.g. to quickly generate a debug build (e.g. by
setting CFLAGS=-g), but Pybind11Extension currently unconditionally
overwrites this with -g0.
Instead, check the environment variables and only insert -g0 if not
overridden by them.
* fix: add missing std::forward calls
Two of the four cpp_function overloads are missing std::forward calls, which seems like a simple oversight.
* add test for https://github.com/pybind/pybind11/pull/3443
* add py tests
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* fix test
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Simply has_kw_only_args handling
This simplifies tracking the number of kw-only args by instead tracking
the number of positional arguments (which is really what we care about
everywhere this is used).
* Allow keyword-only arguments to follow py::args
This removes the constraint that py::args has to be last (or
second-last, with py::kwargs) and instead makes py::args imply
py::kw_only for any remaining arguments, allowing you to bind a function
that works the same way as a Python function such as:
def f(a, *args, b):
return a * b + sum(args)
f(10, 1, 2, 3, b=20) # == 206
With this change, you can bind such a function using:
m.def("f", [](int a, py::args args, int b) { /* ... */ },
"a"_a, "b"_a);
Or, to be more explicit about the keyword-only arguments:
m.def("g", [](int a, py::args args, int b) { /* ... */ },
"a"_a, py::kw_only{}, "b"_a);
(The only difference between the two is that the latter will fail at
binding time if the `kw_only{}` doesn't match the `py::args` position).
This doesn't affect backwards compatibility at all because, currently,
you can't have a py::args anywhere except the end/2nd-last.
* Take args/kwargs by const lvalue ref
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
