@davidhewitt this is ready for another review

It looks like there's a compile error on the pipeline still:

It looks like the pipeline is still failing with this same error. I think you should be able to reproduce by running cargo test --lib --features=abi3-py37

After making the suggested change, we are getting the following error:

error: cannot find attribute pyo3 in this scope
--> src/tests/hygiene/pyclass.rs:12:46
|
12 | #[cfg_attr(any(Py_3_9, not(Py_LIMITED_API)), pyo3(weakref))]

How do I fix this? Do I need to add an import? Rust Rover doesn't give any suggestions.

Ungh, I realise now that with that suggestion I've blundered right into #2786 (and similar pains around cfg_attr).

I think the solution for now here would be to still use cfg_attr but wrap the whole pyclass in the attribute.

So something like

#[cfg_attr(any(Py_3_9, not(Py_LIMITED_API)), crate::pyclass(name = "ActuallyBar", ..., weakref))]
#[cfg_attr(not(any(Py_3_9, not(Py_LIMITED_API))), crate::pyclass(name = "ActuallyBar", ...))]
pub struct Bar {

Thanks for working on this at the PyCon sprints! 🚀

It looks like there's a compile error on the pipeline still:

error: `weakref` requires >= python 3.9 with the `abi3` feature
  --> src/tests/hygiene/pyclass.rs:16:5
   |
16 |     weakref,
   |     ^^^^^^^

I'd suggest having a look at that file and moving the weakref flag to a separate #[cfg_attr(any(Py_3_9, not(Py_LIMITED_API)), pyo3(weakref))].

I made this change and it gives a compiler error. I don't know rust well enough to even guess how to fix it. Do you have any suggestions?

I pushed a commit to apply something which should work as per #4194 (comment)

Ah, there was a lot of adjustment to conditional compilation to follow up where our own test suite had been silently ignoring the missing behaviour. Good to find that this makes us in a better place! 😂

I think the CI failure arises due to divergence between how we check for abi3 here and how pyo3-build-config activate the limited API for PyPy / GraalPy. I opened #4237 to simplify.

Where are we at with this PR? What can I do to get it over the line?

@codeguru42 great question! After the last updates I pushed, I think this PR should in principle be good to merge.

But naturally, making these error messages emerge properly has uncovered two pain points that I've been fixing separately. First there was #4237 which fixed a divergence between how we were setting the abi3 feature here in macro code versus in pyo3-ffi.

And then now the tests have picked up an old bug that's my fault with the 3.9 implementation, which I opened this morning in #4251.

My hope is that once that PR is merged, we'll be able to merge this one without further modifications 👀

@davidhewitt I merged main into this branch and resolved conflicts. But I have one question for clarification. As you can see in 3c7e898. main has Py_3_9 as the version for cfg but this branch has Py_3_10. It looks like the change on this branch comes from 7177d53 which you pushed to this PR. I accepted the change from main assuming that it is probably correct, but I want to double-check with you to be sure.

Yep I think main is correct; let's try merging again. Thanks for fixing conflicts 🙏

Hooray, success finally! 🎉 Thanks again @codeguru42 and great to meet you at PyCon 👍

Closes #3945.

I probably don't have permissions to do this...but thought I'd see if a comment would do it. Maybe needed it in the description before merging?