On 10/12/2021 03.08, Jim J. Jewett wrote:
Christian Heimes wrote:
On 09/12/2021 19.26, Petr Viktorin wrote:
If the code is the authoritative source of truth, we need a proper
parser to extract the information. ... unfortunately I don't trust it
enough to let it define the API. Bugs in the parser could result in
the API definition silently changing.
There are other options than writing a new parser. GCC and Clang are
flexible. For example GCC can be extended with plugins and custom
attributes.
But they have the same problem ... it can be difficult to know if there is a
subtle bug in someone's understanding of how the plugin interacts with, for
example, nested ifndef.
The failure mode for an explicitly manually maintained text file is that
something doesn't get added when it should, and the more conservative API
consumers wait an extra release before using it.
Macros and ifndefs are not a problem. A GCC plugin for user-defined
attributes hooks into the build process at a late stage. By the time the
plugin hook is invoked, the precompiler has resolved all macros and
ifdefs, and the C code has been parsed. The plugin operates on the same
intermediate code as the compiler.
The approach would allow us to make the headers the authoritative source
for most API and ABI symbols. I don't think that we can use it for
macros. We can even include additional metadata in the custom attribute,
e.g. version added
PyAPI_ABI_FUNC("3.2", PyObject *) PyLong_FromLong(long);
We can convert Misc/stable_abi.txt into an auto-generated file. The file
should still stay in git, so we can use it to verify the stable ABI in CI.
Christian
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/5GSBMLBCXC3THYZYXC5E627CGQELE6JI/
Code of Conduct: http://python.org/psf/codeofconduct/