Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: 0.22.3 #4518

Merged
merged 32 commits into from
Sep 15, 2024
Merged

release: 0.22.3 #4518

merged 32 commits into from
Sep 15, 2024

Conversation

davidhewitt
Copy link
Member

I think we've accumulated a lot of fixes (and a whole lot of non-breaking improvements) which would be good to release, and it seems we're still a little way away from 0.23.

So I'll start preparing this branch for release and hope to put this live soon once we have a passing CI.

davidhewitt and others added 18 commits September 3, 2024 14:16
…4349)

* Improve error messages for #[pyfunction] defined inside #[pymethods]

Make error message more specific when `#[pyfunction]` is used in
`#[pymethods]`.

Effectively, this replaces the error message:

```
error: static method needs #[staticmethod] attribute
```

To:
```
functions inside #[pymethods] do not need to be annotated with #[pyfunction]
```

...and also removes the other misleading error messages to the function in
question.

Fixes #4340

Co-authored-by: László Vaskó <1771332+vlaci@users.noreply.github.com>

* review fixes

---------

Co-authored-by: László Vaskó <1771332+vlaci@users.noreply.github.com>
* Update dict.get_item binding to use PyDict_GetItemRef

Refs #4265

* test: add test for dict.get_item error path

* test: add test for dict.get_item error path

* test: add test for dict.get_item error path

* fix: fix logic error in dict.get_item bindings

* update: apply david's review suggestions for dict.get_item bindings

* update: create ffi::compat to store compatibility shims

* update: move PyDict_GetItemRef bindings to spot in order from dictobject.h

* build: fix build warning with --no-default-features

* doc: expand release note fragments

* fix: fix clippy warnings

* respond to review comments

* Apply suggestion from @mejrs

* refactor so cfg is applied to functions

* properly set cfgs

* fix clippy lints

* Apply @davidhewitt's suggestion

* deal with upstream deprecation of new_bound
* fix: updated pyclass heighten check to validate for eq and ord, fixing Ok issue in eq implementation.

identified similar issues in Complex enum and tuple enum,  resolved serveral cases, but working on current error coming from traits not being in scope

* fix: fully qualified clone and from calls for enums.

* update: added changelog entry

---------

Co-authored-by: MG <mg@rookie.ninja>
#4382)

* fix incorrect spans on `ret` and `py` local varianbles in emitted code

* add newsfragment
Fixes #4400

As the return value is ultimately communicated back via a StopIteration
exception instance, a peculiar behavior of `PyErr::new` is encountered
here: when the argument is a tuple `arg`, it is used to construct the
exception as if calling from Python `Exception(*arg)` and not
`Exception(arg)` like for every other type of argument.

This comes from from CPython's `PyErr_SetObject` which ultimately calls
`_PyErr_CreateException` where the "culprit" is found here:
https://github.com/python/cpython/blob/main/Python/errors.c#L33

We can fix this particular bug in the invocation of `PyErr::new` but it
is a more general question if we want to keep reflecting this somewhat
surprising CPython behavior, or create a better API, introducing a
breaking change.
* Add PyList_GetItemRef bindings and compat shim

* Use PyList_GetItemRef in list.get_item()

* add release notes

* apply code review comments

* Update newsfragments/4410.added.md

Co-authored-by: David Hewitt <mail@davidhewitt.dev>

* apply `all()` doc cfg hints

---------

Co-authored-by: David Hewitt <mail@davidhewitt.dev>
From now you cannot initialize a `PyClassInitializer<SubClass>` with `PyClassInitializer::from(Py<BaseClass>).add_subclass(SubClass)`.

This was out of bounds write. Now it panics. See details at #4452.
* ffi: define compat for `Py_NewRef` and `Py_XNewRef`

* add missing inline hint

Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>

* don't use std::ffi::c_int (requires MSRV 1.64)

* add test to guard against ambiguity

* fix `Py_NewRef` cfg on PyPy

---------

Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
* Use vectorcall (where possible) when calling Python functions

This works without any changes to user code.

The way it works is by creating a methods on `IntoPy` to call functions, and specializing them for tuples.

This currently supports only non-kwargs for methods, and kwargs with somewhat slow approach (converting from PyDict) for functions. This can be improved, but that will require additional API.

We may consider adding more impls IntoPy<Py<PyTuple>> that specialize (for example, for arrays and `Vec`), but this i a good start.

* Add vectorcall benchmarks

* Fix Clippy (elide a lifetime)

---------

Co-authored-by: David Hewitt <mail@davidhewitt.dev>
@davidhewitt
Copy link
Member Author

semver-checks failure is on the PyObjectInit trait, which is private to implement (but just uses an antiquated mechanism rather than sealing). We should fix that. It's not a blocker for patch release.

birkenfeld and others added 4 commits September 13, 2024 11:51
)

* type_object: fix new clippy complaint about length of doc comment

* all: replace minor version specific links to CPython docs
* ci: fix nightly warning about unreachable pattern

* add comment
@davidhewitt davidhewitt marked this pull request as ready for review September 13, 2024 12:53
@davidhewitt
Copy link
Member Author

Ok, with CI now green I've pushed a release commit with a suggested release date of the 15th (Sunday).

There is a very minor breaking change in the removal of _Py_PackageContext private FFI definition. As users shouldn't be using this anyway (it got removed in 3.13 I think), then I don't really think this is a bad thing if it breaks builds now. I think the risk of actual usage is very low though, so impact will be minor.

I delayed similar removals of _Py_NewRef and _Py_XNewRef until 0.23 as they are just local reimplementations of macros so won't break in the same way.

If I hear no reason to delay, will put this live on Sunday!

@davidhewitt
Copy link
Member Author

Will release this now.

@davidhewitt davidhewitt merged commit cd5369c into release-0.22 Sep 15, 2024
77 of 78 checks passed
@davidhewitt davidhewitt deleted the release-0.22.3 branch September 15, 2024 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants