2923: hygiene: fix `#[pymethods(crate = "...")]` r=davidhewitt a=davidhewitt
Got to the bottom of the hygiene issue in test of #2914
Turns out that `#[pymethods] #[pyo3(crate = "...")]` works, but `#[pymethods(crate = "...")]` was ignoring the argument.
Added a tweak to fix this and a snippet in the hygiene test (which fails on `main`).
2924: remove unneeded into_iter calls r=davidhewitt a=davidhewitt
Clippy complaining about these to me this morning locally.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2904: refactor docstring generation code r=mejrs a=davidhewitt
As a first step towards #2866 this is a tweak to the macro code which generates Python docstrings. This PR refactors the behaviour so that instead of always creating a `concat!` expression to generate a nul-terminated string, this will only happen if a Rust 1.54+ macro doc is present (e.g. `#[doc = include_str!(...)]`).
The default case now just collects all the `#[doc]` attributes into a single string.
This should make it easier to factor out the `text_signature` formatting, and avoids wasting compile time invoking the `concat!` macro when not necessary.
2921: Check to see if object is `None` before traversing r=davidhewitt a=neachdainn
Closes#2915
When using the C API directly, the intended way to call `visitproc` is via the `Py_VISIT` macro, which checks to see that the provided pointer is not null before passing it along to `visitproc`. Because PyO3 isn't using the macro, it needs to manually check that the pointer isn't null. Without this check, calling `visit.call(&obj)` where `let obj = None;` will segfault.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Nate Kent <nate@nkent.net>
Closes#2915
When using the C API directly, the intended way to call `visitproc` is
via the `Py_VISIT` macro, which checks to see that the provided pointer
is not null before passing it along to `visitproc`. Because PyO3 isn't
using the macro, it needs to manually check that the pointer isn't null.
Without this check, calling `visit.call(&obj)` where `let obj = None;`
will segfault.
2796: Forward cfgs on pyclass fields to the method defs r=davidhewitt a=mejrs
With this and the cfg_attr PR, I don't need cfg_eval at all anymore :)
- [x] needs some more tests
Co-authored-by: mejrs <>
2843: remove functionality deprecated in 0.16 r=davidhewitt a=davidhewitt
Simple cleanup to remove all functionality marked deprecated in the 0.16 releases.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2842: Stop leaking in `new_closure` r=adamreichold a=davidhewitt
This is a rebase of #2690 which simplifies the `MaybeLeaked` abstraction from that PR with just `Cow<'static, CStr>`.
This enabled me to annotate with `FIXME` all the places where we still leak; I wonder if we could potentially use `GILOnceCell` in future and statics to avoid those. As those callsities are in `#[pyclass]` and `#[pyfunction]` these are effectively in statics anyway, but it would be nice to tidy up.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2838: pypy: re-enable PyFunction on 3.8+ r=davidhewitt a=davidhewitt
PyPy [fixed the crashes associated with `PyFunction](https://foss.heptapod.net/pypy/pypy/-/issues/3776#note_191626) in PyPy 7.3.10 (for 3.8+) - which I think is to be released shortly. So I think we should re-enable this API and treat it as a PyPy bug which users can mitigate by updating their PyPy.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2398: Add `GILOnceCell::get_or_try_init` r=mejrs a=a1phyr
This is similar to [`OnceCell::get_or_try_init`](https://docs.rs/once_cell/latest/once_cell/sync/struct.OnceCell.html#method.get_or_try_init) and is very useful for fallible initialization.
Co-authored-by: Benoît du Garreau <bdgdlm@outlook.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2826: ci: run checks for all platforms on PR r=adamreichold a=davidhewitt
I've been struggling a little to merge PRs with the new bors workflow; overall I think the lighter PR workflow is better but the number of combinations of older pythons / platforms not covered makes it easy for the bors step to fail.
This PR tries to improve the situation by merging the `clippy` and `check-target` job and running it for all supported platforms on PR. Hopefully if these are green, then there's high likelihood that tests will build and should pass unless there's logic errors.
While creating this I found a build error on PyPy which made me notice we can support `PyList::get_item_unchecked` for PyPy, so I added it.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2784: Automatically generate `__text_signature__` for all functions r=davidhewitt a=davidhewitt
This PR makes it so that PyO3 generates `__text_signature__` by default for all functions. It also introduces `#[pyo3(text_signature = false)]` to disable the built-in generation.
There are a few limitations which we can improve later:
- All default values are currently set to `...`. I think this is ok because `.pyi` files often do the same. Maybe for numbers, strings, `None` and `True`/`False` we could render these in a future PR.
- No support for `#[new]` yet.
Alternative design ideas:
- Only autogenerate for methods with `#[pyo3(signature = (...))]` annotation. I started with this, and then decided it made sense to do it for everything.
- Opt-out with `#[pyo3(text_signature = None)]`. This is slightly harder to parse in the macro, but matches the final result in Python better, so if this looks preferable to others, I can change from `text_signature = false` to `text_signature = None`.
There's some small tidying up / refactoring to do before this merges (happy to take suggestions on this), however the general logic, design and docs are ready for review.
2827: pypy: enable `PyList::get_item_unchecked` r=adamreichold a=davidhewitt
Split out from #2826. Approved previously as part of that review.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
This appears to be the only way to chain exceptions via the FFI. It
was introduced prior to CPython 3.7. It has some description of usage
in PEP 490. There was a discussion of whether it should be made stable
in BPO 44938.
