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.
