fix 3.15+ append_to_inittab on platforms which aren't 64-bit little-endian

[davidhewitt]

Fixes #6143

On 3.15, m_slots: slots.0.get() as _ was hiding a cast from *mut [PySlot; N] to *mut PyModuleDef_Slot. On 64-bit little-endian this happens to be ok, which is why we never noticed.

[davidhewitt]

cc @decathorpe, do you happen to have a way to test with this patch to confirm?

I would also love if you have any ideas how we could test for 32-bit platform and/or s390x on CI; at the moment we run clippy for a bunch of platforms but I think you've hit a number of bugs on these platforms now. Hugely appreciate the patient reports but also feel like maybe it's time we considered if there's anything else we can do here to minimise the amount of issues which make it downstream to you.

[Person-93]

@davidhewitt I think QEMU can emulate both of those platforms. I have not tried using QEMU in a gtihub action runner, but it should work. So in CI, you can cross-compile and then run the test binary with QEMU.

[alex]

For 32-bit, it's possible to run a 32-bit Python binary on GHA Window. It's slow, though not as slow as emulation.

[decathorpe]

cc @decathorpe, do you happen to have a way to test with this patch to confirm?

Yes, I can. I've launched a test build with this PR included, I will report back once I get the results.

I would also love if you have any ideas how we could test for 32-bit platform and/or s390x on CI; at the moment we run clippy for a bunch of platforms but I think you've hit a number of bugs on these platforms now. Hugely appreciate the patient reports but also feel like maybe it's time we considered if there's anything else we can do here to minimise the amount of issues which make it downstream to you.

Yeah I think emulation is going to be the only workable solution here - Cirrus CI used to provide more architectures I think, but that's no longer an option.

@davidhewitt I think QEMU can emulate both of those platforms. I have not tried using QEMU in a gtihub action runner, but it should work. So in CI, you can cross-compile and then run the test binary with QEMU.

Relatedly, depending on what test coverage you'd want, I think you'd also need to compile on the target platform, not cross-compile. Last time I checked, doctests did not support getting cross-compiled, so without compiling on the target platform, those wouldn't be covered by tests.

[decathorpe]

Seems like the patch from this PR doesn't apply cleanly on top of 0.29.0, I'm getting compilation failures:

error[E0609]: no field `0` on type `PyModuleSlots`
   --> src/impl_/pymodule.rs:634:67
    |
634 |             assert_eq!((*module_def.ffi_def.get()).m_slots, SLOTS.0.get().cast());
    |                                                                   ^ unknown field
    |
    = note: available fields are: `pep_820_slots`, `pep_489_slots`
error[E0609]: no field `values` on type `PyModuleSlotsBuilder`
   --> src/impl_/pymodule.rs:652:35
    |
652 |         let second_last = builder.values[builder.len - 1];
    |                                   ^^^^^^ unknown field
    |
    = note: available fields are: `slots`, `len`
error[E0609]: no field `values` on type `PyModuleSlotsBuilder`
   --> src/impl_/pymodule.rs:653:28
    |
653 |         let last = builder.values[builder.len];
    |                            ^^^^^^ unknown field
    |
    = note: available fields are: `slots`, `len`

I will try to test this PR directly instead of applying it as a patch on top of 0.29.0.

EDIT: Nevermind, looks like the new code on the branch linked to this PR just doesn't compile.