Add PyPy3.11

[mattip]

Support PyPy's python3.11. It is not officially released yet, but I wanted to be sure PyO3 works.
I am testing this branch elsewhere. Until there is an official release, I set the PR to use the nightly builds.

You may wish to hold off on merging this until the official release, that is fine with me.

Also I dropped PyPy3.9 since we no longer support it. Nothing has changed so it should JustWork(tm)

I had help from the discussions, thanks!

[mattip]

Hmm. There is a unused declaration error. Any suggestions how to fix that?

 error: unused import: `c_char`
   --> pyo3-ffi/src/cpython/abstract_.rs:2:20
    |
  2 | use std::os::raw::{c_char, c_int};
    |                    ^^^^^^
    |
    = note: `-D unused-imports` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unused_imports)]`
  
  error: unused import: `std::os::raw::c_char`
   --> pyo3-ffi/src/cpython/genobject.rs:6:5
    |
  6 | use std::os::raw::c_char;
    |     ^^^^^^^^^^^^^^^^^^^^
  
  error: unused import: `libc::size_t`
   --> pyo3-ffi/src/cpython/objimpl.rs:1:5
    |
  1 | use libc::size_t;
    |     ^^^^^^^^^^^^
  
  error: could not compile `pyo3-ffi` (lib) due to 3 previous errors

[Icxolu]

These occur because with this there are new cfg combinations possible that weren't possible before (and therefore not tested for). To get rid of the warnings you need to add cfgs to them, so we only import them when they are needed.

In the order from the error above, I think these should be 🤞:

• #[cfg(any(all(Py_3_8, not(any(PyPy, GraalPy))), not(Py_3_11)))]
• #[cfg(all(not(PyPy), not(GraalPy), Py_3_11))]
• #[cfg(any(all(not(PyPy), not(GraalPy)), not(Py_3_11)))]

[mattip]

Thanks, let's try it

[mattip]

Yup, that seems to have done the trick. Is there anything else I should try? I will mark this as "draft" since it can wait for the release to be merged.

[davidhewitt]

Thanks, I added a label so that the full CI will trigger if you push again to this branch. This should execute more PyPy3.11 jobs and give better feedback.

Aside, if pypy/pypy#3836 ever gets resolved it will vastly increase the amount of testing of PyPy we can do here, because we have an absolute heap of tests which use Py_Initialize to spawn interpreters and run basic checks. I think it's out of scope for me to find time to work on that for the foreseeable future sadly.

[davidhewitt]

Please rename this to 4760.packaging.md - we put the packaging section at the top so easier for users to notice this.

[mattip]

Unfortunately we are also unlikely to implement Py_Initialize. To do it properly would require first refactoring the startup code in pypy/interpreter/app_main.py and pypy/module/sys to use a CPython-like startup sequence with a configuration object.

[mattip]

rebased off main to clear some conflicts

[mattip]

PyPy 7.3.18 with Python3.11 has been released so I am marking this ready for review.

[alex]

looks like many CI jobs are still failing, those will need to be resolved

[mattip]

I don't understand how this PR is causing hypothesis to time out when generating samples:

     @given(x=INTEGER32_ST)
  >   def test_double(x):
  E   hypothesis.errors.FailedHealthCheck: It looks like your strategy is filtering out a lot of data. Health check found 50 filtered examples but only 7 good ones. This will make your tests much slower, and also will probably distort the data generation quite a lot. You should adapt your strategy to filter less. This can also be caused by a low max_leaves parameter in recursive() calls

[Icxolu]

I don't understand how this PR is causing hypothesis to time out when generating samples:

I believe this was fixed in #4879, so probably a rebase is enough to fix it.

[mattip]

rebased and force-pushed.

[mattip]

Huh. No idea why CI is failing.

[alex]

I believe this is a known false positive in clippy