You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
graminit.h defines very generic names like 'stmt' or 'test' #79378
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2021-05-26.22:43:50.488>created_at=<Date2018-11-09.14:06:44.804>labels= ['interpreter-core', '3.8']
title="graminit.h defines very generic names like 'stmt' or 'test'"updated_at=<Date2021-05-26.22:44:32.369>user='https://github.com/vstinner'
The preprocessor replaces "exp->v.IfExp.test" with "exp->v.IfExp.305" which is invalid...
The compile.h header file works around the issue by redefining 3 constants but using "Py_" prefix:
/* These definitions must match corresponding definitions in graminit.h. There's code in compile.c that checks that they are the same. */#definePy_single_input 256
#definePy_file_input 257
#definePy_eval_input 258
Do nothing: require to include graminit.h at the right place
Add a prefix to all symbols, ex: test => Py_test, grammar_test, etc.
Rename problematic names like 'test' and 'stmt'
Fix C code to avoid problematic name: 'test' is an an attribute name of a node struct...
Note: "static const int single_input = 305;" cause a complation error on "case single_input": "case label does not reduce to an integer constant".
IMHO adding a prefix would be a nice enhancement and a good compromise. It only impacts the four C files which include graminit.h: future.c, ast.c, parsetok.c and parsermodule.c.
I think it would be better to exclude graminit.h from the set of distributed headers. It is internal generated file, it should not be used by any user code.
Some constants are duplicated as a part of public API in compile.h.
graminit.h is included in few files, and not always its inclusion is necessary. Here is a patch that minimizes its inclusion. It is not ready for merging, it is just a demo.
I think it would be better to exclude graminit.h from the set of distributed headers. It is internal generated file, it should not be used by any user code.
I'm fine with moving it to Include/internal/. Do you know if it's used outside CPython?
It can be used by the code that works directly with CST instead of AST: (...)
Sorry, I don't know this part of CPython. Is the CST exposed in any way outside CPython internals? If no, I see no reason to expose graminit.h in the public C API.
I moved the evil public Python-ast.h header file into the internal C API as Include/internal/pycore_ast.h. It doesn't define "Yield" anymore: "_PyAST_Yield" must be used instead.
Activity
vstinner commentedon Nov 9, 2018
graminit.h is an header file associating Grammar entities to their values, example:
Problem: defines symbols have no prefix and cause compilation issues on regular C code depending where graminit.h is included. Example with ast.c:
"#define stmt 269" causes a compilation issue, the preprocessor replaces the code with:
... which is invalid.
Another example:
The preprocessor replaces "exp->v.IfExp.test" with "exp->v.IfExp.305" which is invalid...
The compile.h header file works around the issue by redefining 3 constants but using "Py_" prefix:
For comparison, graminit.h uses:
There are different solutions:
Note: "static const int single_input = 305;" cause a complation error on "case single_input": "case label does not reduce to an integer constant".
IMHO adding a prefix would be a nice enhancement and a good compromise. It only impacts the four C files which include graminit.h: future.c, ast.c, parsetok.c and parsermodule.c.
vstinner commentedon Nov 9, 2018
Ah! A friend gave me another solution, define an enum. Example:
enum {
single_input = 256,
...
};
vstinner commentedon Nov 9, 2018
Current workaround in ast.c:
This code is in the "middle" of ast.c.
serhiy-storchaka commentedon Nov 9, 2018
I think it would be better to exclude graminit.h from the set of distributed headers. It is internal generated file, it should not be used by any user code.
Some constants are duplicated as a part of public API in compile.h.
serhiy-storchaka commentedon Nov 9, 2018
graminit.h is included in few files, and not always its inclusion is necessary. Here is a patch that minimizes its inclusion. It is not ready for merging, it is just a demo.
vstinner commentedon Nov 9, 2018
I'm fine with moving it to Include/internal/. Do you know if it's used outside CPython?
pablogsal commentedon Nov 9, 2018
Although not a complete view, all of the mentions I can find in GitHub is in copies of CPython/forks/vendoring of Cpython:
https://github.com/search?l=C&p=13&q=graminit.h&type=Code
serhiy-storchaka commentedon Nov 9, 2018
It can be used by the code that works directly with CST instead of AST: these constants are used as values of the n_type field of the node structure.
vstinner commentedon Nov 9, 2018
Sorry, I don't know this part of CPython. Is the CST exposed in any way outside CPython internals? If no, I see no reason to expose graminit.h in the public C API.
vstinner commentedon May 14, 2019
Another common issue with Python-ast.h, I just saw it on Windows:
compile.c
c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\winbase.h(102): warning C4005: 'Yield': macro redefinition [C:\vstinner\python\master\PCbuild\pythoncore
.vcxproj]
c:\vstinner\python\master\include\python-ast.h(627): note: see previous definition of 'Yield'
vstinner commentedon May 26, 2021
Issue fixed in bpo-43244.
I moved the evil public Python-ast.h header file into the internal C API as Include/internal/pycore_ast.h. It doesn't define "Yield" anymore: "_PyAST_Yield" must be used instead.
vstinner commentedon May 26, 2021
Moreover, graminit.h was removed in Python 3.10.