GeezerVison is showing github.com — Cython cannot use "pycore_frame.h" in Py3.14a4 · Issue #130931 · python/cpython
Cython cannot use "pycore_frame.h" in Py3.14a4 #130931DescriptionBug report
Bug description:
It's this time of the year again. As discussed before (e.g. #123747), Cython #includes CPython's pycore_frame.h to get access to certain frame features, e.g. their integration into tracebacks.
I noticed that Cython generated code doesn't compile in CPython 3.14 alpha with the following kind of errors:
…\Python\3.14.0-alpha.4\x64\include\internal\pycore_stackref.h(278): error C7555: use of designated initializers requires at least '/std:c++20'
…\Python\3.14.0-alpha.4\x64\include\internal/pycore_frame.h(196): error C7555: use of designated initializers requires at least '/std:c++20'
…\Python\3.14.0-alpha.4\x64\include\internal/pycore_frame.h(196): error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
…\Python\3.14.0-alpha.4\x64\include\internal/pycore_frame.h(378): error C7555: use of designated initializers requires at least '/std:c++20'
…\Python\3.14.0-alpha.4\x64\include\internal/pycore_frame.h(378): error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
…\Python\3.14.0-alpha.4\x64\include\internal/pycore_frame.h(379): error C7555: use of designated initializers requires at least '/std:c++20'
…\Python\3.14.0-alpha.4\x64\include\internal/pycore_frame.h(379): error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
This is from one of our Windows CI runs. Py3.14a4 seems to be what Github Actions currently provides. Cython code expects C99 and something close to (but not necessarily as complete as) C++11 as compiler standards. It targets both C and C++, depending on user needs.
The dependency on pycore_stackref.h was apparently added in #118450:
22b0de2755e [2024-06-27 03:10:43 +0800] GitHub | gh-117139: Convert the evaluation stack to stack refs (#118450)
diff --git a/Include/internal/pycore_frame.h b/Include/internal/pycore_frame.h
index bab92c771a7..1e0368faa5b 100644
--- a/Include/internal/pycore_frame.h
+++ b/Include/internal/pycore_frame.h
@@ -11,6 +11,7 @@ extern "C" {
#include <stdbool.h>
#include <stddef.h> // offsetof()
#include "pycore_code.h" // STATS
+#include "pycore_stackref.h" // _PyStackRef
/* See Objects/frame_layout.md for an explanation of the frame stack
* including explanation of the PyFrameObject and _PyInterpreterFrame
@@ -67,7 +68,7 @@ typedef struct _PyInterpreterFrame {
uint16_t return_offset; /* Only relevant during a function call */
char owner;
/* Locals and stack */
- PyObject *localsplus[1];
+ _PyStackRef localsplus[1];
} _PyInterpreterFrame;
#define _PyInterpreterFrame_LASTI(IF) \What can we do to resolve this?
CPython versions tested on:
3.14
Operating systems tested on:
Windows
Linked PRs
Activityscoder commented on Mar 7, 2025 ContributorAuthor More actions encukou commented on Mar 7, 2025 Added by @Fidget-Spinner & @colesbury, back in June.
What kind of public/unstable API would Cython need so it could avoid the internal headers? Fidget-Spinner commented on Mar 7, 2025 I think we should be able to make it compliant with the C compiler Cython is using scoder commented on Mar 7, 2025 ContributorAuthor More actions Fidget-Spinner commented on Mar 7, 2025 @scoder could you please point out the C++ standard violations in your CPython alpha? The line number you posted for the alpha doesn't seem to match up with the current source. I think there's been some changes between then. Thanks! scoder commented on Mar 7, 2025 ContributorAuthor More actions
The line number you posted for the alpha doesn't seem to match up with the current source.
Yeah, this output was copied from a Github Actions run of MSVC, which notoriously reports randomly displaced line numbers. I regularly end up looking broadly around the reported lines to guess my way towards potential code candidates for the reported errors and warnings. I have no idea how people can make productive use of such a compiler.
I actually failed to find any designated initializers in pycore_frame.h myself, but they are definitely used in pycore_stackref.h. The issue then is that they long existed in C99 but only came into C++ very late, in C++20. Usually not an issue for internal headers in a C project like CPython these days, unless someone needs to access internal headers from C++ code. Fidget-Spinner commented on Mar 7, 2025 Ok if it's just removing the designated initializers that should be easy enough to do. I'll take this up. encukou commented on Mar 7, 2025 #define PyStackRef_True ((_PyStackRef){.bits = (uintptr_t)&_Py_TrueStruct })
#define PyStackRef_False ((_PyStackRef){.bits = ((uintptr_t)&_Py_FalseStruct) })
#define PyStackRef_None ((_PyStackRef){.bits = ((uintptr_t)&_Py_NoneStruct) })
I'm afraid the compiler complaints are about two features: C7555 is for designated initializers but C4576 is for compound literals (the cast-like syntax). Fidget-Spinner commented on Mar 7, 2025 I think I'm going to wait for @markshannon to land his PR on stackrefs first. Fidget-Spinner commented on Mar 7, 2025 @encukou the cast-like syntax is going to be hard to fix without losing some performance on msvc. I'm not sure what to do for those. Any thoughts? encukou commented on Mar 7, 2025 Expose the frame struct (and only that) more? Unstable API is probably the best place for it given Cython's usage; unfortunately #31530 predated PEP-689.
So, rename struct _frame to PyUnstable_FrameObject, move it to Include/cpython/frameobject.h and document it? encukou commented on Mar 7, 2025 (I'm happy to do that, especially the docs part, if that seems right to y'all) encukou commented on Apr 29, 2025 To set expectations: I won't work on this in the foreseeable future. Happy to do reviews. vstinner commented on Oct 9, 2025 The initial issue (Cython cannot use "pycore_frame.h" in Py3.14a4) has been fixed. Can we close this issue? picnixz commented on Oct 9, 2025 I believe so (sorry for all those labels; I thought it was a new issue) encukou commented on Oct 9, 2025 picnixz commented on Oct 9, 2025 Couldn't we open a separate issue for this one in particular? it's burried in the list of comments and not visible by default. It's also a separate matter (a new feature that will need docs & co, nothing to do with the current title) Reacted by Victor Stinner and Petr Viktorin
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|