Issue 39355: The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword

The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword
 
For example, in warnings.h, we have the following code:
 
#ifndef Py_LIMITED_API
PyAPI_FUNC(int) PyErr_WarnExplicitObject(
    PyObject *category,
    PyObject *message,
    PyObject *filename,
    int lineno,
    PyObject *module,
PyObject *registry);
 
 
In modsupport.h we have the following code:
PyAPI_FUNC(int) PyModule_ExecDef(PyObject *module, PyModuleDef *def);
 
We can fix this by using a different identifier, for example “pyModule” instead of “module”

Names of arguments can be just removed from function declarations in header files.

Qt has a similar issue with "slots": bpo-1086854 and bpo-38007.

Qt has different issue. "slots" is not a keyword, and the issue can be avoided by including Python.h before Qt.h or undefining the "slots" macro.

It could be a harder issue if "module" would be a field name of a public structure. But names of arguments are not part of the API.

If nobody works, i would like to solve this

Please go ahead. Anyone is free to propose a fix.

We have tested with cxx-modules that issue.
module is just a specifier for export (only export is a compiler-based keyword in >= C++20)
That's why we can use module as argument name and there's no need to rename or delete *module arguments from header files.

What do you recommend to do?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1103r3.pdf

the word "module" should be treated as a reserved keyword.

Any use of "module" as an argument name should be changed to something else
throughout the code base.

On Fri, Aug 20, 2021 at 11:28 PM Hasan <report@bugs.python.org> wrote:

>
> Hasan <hasan.aleeyev@gmail.com> added the comment:
>
> We have tested with cxx-modules that issue.
> module is just a specifier for export (only export is a compiler-based
> keyword in >= C++20)
> That's why we can use module as argument name and there's no need to
> rename or delete *module arguments from header files.
>
> What do you recommend to do?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1103r3.pdf
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue39355>
> _______________________________________
>

Okey. There will be huge changes for this issue as this keyword has been used in a lot of places. 

That's why i will try to send pull requests module by module to keep it clean and simple for review.

> There will be huge changes for this issue as this keyword has been used in a lot of places.

For external extension modules, it should be sufficient to change only the exposed headers; that is Include/*.h and Include/cpython/*.h. We should also change the AC tool, since that may be used by external projects.

> The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword

What is the error message? How can the error be reproduced?

Compile with a compiler supporting the C++20 core feature (Modules)

https://en.cppreference.com/w/cpp/compiler_support

In visual studio, use  C/C++ > Language > CPP Language Standard > C++20 or
higher

On Mon, Mar 7, 2022 at 5:32 PM STINNER Victor <report@bugs.python.org>
wrote:

>
> STINNER Victor <vstinner@python.org> added the comment:
>
> > The Python library will not compile with a C++2020 compiler because the
> code uses the reserved “module” keyword
>
> What is the error message? How can the error be reproduced?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue39355>
> _______________________________________
>

If I build a C++ extension with -std=c++20, I get a compiler error on PyModuleDef_HEAD_INIT:

Modules/_testcppext.cpp:419:5: error: either all initializer clauses should be designated or none of them should be
  419 |     .m_name = "_testcppext",
      |     ^

Code:
---
static struct PyModuleDef module = {
    PyModuleDef_HEAD_INIT,
    .m_name = "_testcppext",
    .m_doc = module_doc,
    ...
};
---

Macro defined as (simplified code):
---
#define PyObject_HEAD_INIT(type) \
    { 1, type },

#define PyModuleDef_HEAD_INIT { \
    PyObject_HEAD_INIT(NULL)    \
    NULL, /* m_init */          \
    0,    /* m_index */         \
    NULL, /* m_copy */          \
  }
---

When I wrote a PR to use the C header file pythoncapi_compat.h in the datatable C++ project, I got multiple C++ compiler warnings in static inline functions and in some macros:
https://github.com/h2oai/datatable/pull/3231#issuecomment-1032864790

* Usage of NULL
* Usage of "old-style cast" like (ssize_t)1 or (PyObject*)obj

I solved this issue in pythoncapi_compat.h by using reinterpret_cast and nullptr:

* https://github.com/python/pythoncapi_compat/commit/347746379f79fa091017e23427932c9f9980234d
* https://github.com/python/pythoncapi_compat/pull/18
* https://github.com/h2oai/datatable/pull/3237

By the way, pythoncapi_compat.h no longer uses "module":
https://github.com/python/pythoncapi_compat/pull/22

The Python C API has similar issues, but warnings about NULL and old-style cast depend on the C++ compiler flags:

* -Wzero-as-null-pointer-constant
* -Wold-style-cast

STINNER Victor:
> What is the error message? How can the error be reproduced?

Keith (aCuria):
> Compile with a compiler supporting the C++20 core feature (Modules)
> https://en.cppreference.com/w/cpp/compiler_support

I built a C++ extension which calls PyModule_AddType(): I get no warning. I tested GCC and LLVM clang.

Commands:

clang -Wno-unused-result -g -Og -Wall -O0 -fPIC -I/home/vstinner/python/main/Include -I/home/vstinner/python/main -c Modules/_testcppext.cpp -o build/temp.linux-x86_64-3.11-pydebug/Modules/_testcppext.o -I/home/vstinner/python -Werror -Wall -Wextra -Wconversion -Wno-typedef-redefinition -std=c++20 -Wzero-as-null-pointer-constant -Wold-style-cast

gcc -Wno-unused-result -g -Og -Wall -O0 -fPIC -I/home/vstinner/python/main/Include -I/home/vstinner/python/main -c Modules/_testcppext.cpp -o build/temp.linux-x86_64-3.11-pydebug/Modules/_testcppext.o -I/home/vstinner/python -Werror -Wall -Wextra -Wconversion -Wno-typedef-redefinition -std=c++20 -Wzero-as-null-pointer-constant -Wold-style-cast

Reformatted commands:

['clang',
 '-Wno-unused-result',
 '-g',
 '-Og',
 '-Wall',
 '-O0',
 '-fPIC',
 '-I/home/vstinner/python/main/Include',
 '-I/home/vstinner/python/main',
 '-c', 'Modules/_testcppext.cpp',
 '-o', 'build/temp.linux-x86_64-3.11-pydebug/Modules/_testcppext.o',
 '-I/home/vstinner/python',
 '-Werror',
 '-Wall',
 '-Wextra',
 '-Wconversion',
 '-Wno-typedef-redefinition',
 '-std=c++20',
 '-Wzero-as-null-pointer-constant',
 '-Wold-style-cast']

['gcc',
 '-Wno-unused-result',
 '-g',
 '-Og',
 '-Wall',
 '-O0',
 '-fPIC',
 '-I/home/vstinner/python/main/Include',
 '-I/home/vstinner/python/main',
 '-c', 'Modules/_testcppext.cpp',
 '-o', 'build/temp.linux-x86_64-3.11-pydebug/Modules/_testcppext.o',
 '-I/home/vstinner/python',
 '-Werror',
 '-Wall',
 '-Wextra',
 '-Wconversion',
 '-Wno-typedef-redefinition',
 '-std=c++20',
 '-Wzero-as-null-pointer-constant',
 '-Wold-style-cast']

I wrote the draft PR GH-32175 to test https://bugs.python.org/issue39355 and GH-31282. Problem: I don't get any compiler warning or error about the "module" C++20 keyword. I tested GCC 11.2.1 and clang 13.0.0 of Fedora 35.

The C++20 "module" keyword is "contextual keyword". It's only a keyword if the first line if a file contains "module".

* https://en.cppreference.com/w/cpp/language/modules#Module_declarations
* https://en.cppreference.com/w/cpp/keyword/module

It's not the case in any .h file of the Python C API, so Python doesn't need to be changed. I close the issue.

> The C++20 "module" keyword is "contextual keyword". It's only a keyword if the first line if a file contains "module".

Great! No changes needed. Thanks for investigating.

Follow-up issue: bpo-47165 "[C API] Test that the Python C API is compatible with C++".

stage: patch review -> resolved

messages: + msg360106
stage: needs patch