diff options
author | Petr Viktorin <encukou@gmail.com> | 2019-06-02 21:52:20 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2019-06-02 21:52:20 (GMT) |
commit | fb9423fd0a85f06affb8c3a8f25dd598a649aa42 (patch) | |
tree | e44d7ac1b3483da0f95a9f95e6907c1d5036a242 /Objects/dictobject.c | |
parent | e1179a5096fb12297ececd7a1c79969aa5747e28 (diff) | |
download | cpython-fb9423fd0a85f06affb8c3a8f25dd598a649aa42.zip cpython-fb9423fd0a85f06affb8c3a8f25dd598a649aa42.tar.gz cpython-fb9423fd0a85f06affb8c3a8f25dd598a649aa42.tar.bz2 |
bpo-36974: Make tp_call=PyVectorcall_Call work for inherited types (GH-13699)
When inheriting a heap subclass from a vectorcall class that sets
`.tp_call=PyVectorcall_Call` (as recommended in PEP 590), the subclass does
not inherit `_Py_TPFLAGS_HAVE_VECTORCALL`, and thus `PyVectorcall_Call` does
not work for it.
This attempts to solve the issue by:
* always inheriting `tp_vectorcall_offset` unless `tp_call` is overridden
in the subclass
* inheriting _Py_TPFLAGS_HAVE_VECTORCALL for static types, unless `tp_call`
is overridden
* making `PyVectorcall_Call` ignore `_Py_TPFLAGS_HAVE_VECTORCALL`
This means it'll be ever more important to only call `PyVectorcall_Call`
on classes that support vectorcall. In `PyVectorcall_Call`'s intended role
as `tp_call` filler, that's not a problem.
Diffstat (limited to 'Objects/dictobject.c')
0 files changed, 0 insertions, 0 deletions