gh-144490: Fix C++ compatibility in pycore_cell.h

[yoney]

The header already includes an extern "C" guard, suggesting it is intended to be C++ compatible. Adding a cast allows it to compile without -fpermissive.

cc: @colesbury

• Issue: Enhancement request: make pycore_cell.h compile cleanly under C++ #144490

[picnixz]

Do we do this kind of stuff for every calls? do we support -fpermissive flags? should we do it? I would prefer having an issue (maybe an old one) for other places that could be affected by this.

[colesbury]

The internal headers (pycore_xxx.h) are often not C++ compatible, even though they all have extern "C" { guards (often in the wrong places).

The change itself seems fine, but I'm curious how this came up. What's including pycore_cell.h from C++?

[colesbury]

To answer @picnixz, we generally do this sort of thing when people ask, especially when the changes are tiny, but we don't proactively make the internal header files C++ compatible.

[yoney]

What's including pycore_cell.h from C++?

This came up while I’m adapting CinderX to FT-Python: C++ codegen path for LOAD_DEREF/STORE_DEREF ends up including pycore_cell.h and calling the internal helpers as a good starting point (vs. generating the atomic-swap sequence right away). I initially worked around it with wrappers on our side, but since the header already has extern "C" guards and the change is tiny, I wanted to check whether it’s okay to make this compile cleanly from C++.

Also agreed that pycore_* headers aren’t guaranteed to be C++-compatible and may change; in CinderX we already adapt to internal changes per version.

[colesbury]

Ok, make sense. Can you open an issue like @picnixz asked? Also edit the PR title to associate it with the issue.

[yoney]

Created the issue #144490

@picnixz, @colesbury: Thank you so much for the review.

[ZeroIntensity]

Please also add an #include to test_cppext as well, like this:

cpython/Lib/test/test_cppext/extension.cpp

Lines 15 to 19 in b6d8aa4

	#ifdef TEST_INTERNAL_C_API
	// gh-135906: Check for compiler warnings in the internal C API
	# include "internal/pycore_backoff.h"
	# include "internal/pycore_frame.h"
	#endif

That'll make sure we don't break this again someday.

[ZeroIntensity]

Up to you, but I believe we've used _Py_STATIC_CAST for things like this in the past. That will expand to static_cast<type>(expr) in C++, and then the usual (type)(expr) in C.