| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type (GH-15323, GH-16004) (GH-15966)
The instance destructor for a type is responsible for preparing
an instance for deallocation by decrementing the reference counts
of its referents.
If an instance belongs to a heap type, the type object of an instance
has its reference count decremented while for static types, which
are permanently allocated, the type object is unaffected by the
instance destructor.
Previously, the default instance destructor searched the class
hierarchy for an inherited instance destructor and, if present,
would invoke it.
Then, if the instance type is a heap type, it would decrement the
reference count of that heap type. However, this could result in the
premature destruction of a type because the inherited instance
destructor should have already decremented the reference count
of the type object.
This change avoids the premature destruction of the type object
by suppressing the decrement of its reference count when an
inherited, non-default instance destructor has been invoked.
Finally, an assertion on the Py_SIZE of a type was deleted. Heap
types have a non zero size, making this into an incorrect assertion.
https://github.com/python/cpython/pull/15323.
(cherry picked from commit ff023ed36ea260ab64be5895f1f1f087c798987a)
Fixup: https://github.com/python/cpython/pull/16004.
(cherry picked from commit 5e9caeec76119a0d61c25f1466c27b7dbd5115bd)
Co-authored-by: Eddie Elizondo <eduardo.elizondorueda@gmail.com>
|
|
|
|
| |
(GH-15961)
|
|
|
|
|
| |
(cherry picked from commit 60bba83b5d9947fb3106325293e3a4e9c9cdea7e)
Co-authored-by: Valentin Haenel <esc@users.noreply.github.com>
|
|
|
|
|
|
| |
The `wb.len = -1` assignment is unneeded since its introduction in 161d695fb0455ce52530d4f43a9eac4c738f64bb as `PyObject_GetBuffer` always fills it in.
(cherry picked from commit afdeb189e97033b54cef44a7490d89d2013cb4e5)
Co-authored-by: Sergey Fedoseev <fedoseev.sergey@gmail.com>
|
|
|
|
|
|
|
| |
type (GH-15838)
(cherry picked from commit 57ea33560662e0f20a3b0334bb20065771edf4da)
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
|
|
|
|
|
| |
(cherry picked from commit 359143c68659d165f52320d368667e0eff279dc5)
Co-authored-by: dalgarno <32097481+dalgarno@users.noreply.github.com>
|
|
|
| |
This reverts commit 3c452404ae178b742967589a0bb4a5ec768d76e0.
|
|
|
|
|
|
|
| |
(GH-15630) (GH-15635)
Only AttributeError should be silenced.
(cherry picked from commit 41c57b335330ff48af098d47e379e0f9ba09d233)
|
|
|
|
|
| |
(cherry picked from commit 39d87b54715197ca9dcb6902bb43461c0ed701a2)
Co-authored-by: Min ho Kim <minho42@gmail.com>
|
|
|
|
|
|
|
| |
Argument Clinic. (GH-13593). (GH-15599)
(cherry picked from commit 4901fe274bc82b95dc89bcb3de8802a3dfedab32)
Co-authored-by: Rémi Lapeyre <remi.lapeyre@henki.fr>
|
|
|
|
|
| |
(cherry picked from commit 0138c4ceab1e10d42d0aa962d2ae079b46da7671)
Co-authored-by: Raymond Hettinger <rhettinger@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(GH-15491)
- drop TargetScopeError in favour of raising SyntaxError directly
as per the updated PEP 572
- comprehension iteration variables are explicitly local, but
named expression targets in comprehensions are nonlocal or
global. Raise SyntaxError as specified in PEP 572
- named expression targets in the outermost iterable of a
comprehension have an ambiguous target scope. Avoid resolving
that question now by raising SyntaxError. PEP 572
originally required this only for cases where the bound name
conflicts with the iteration variable in the comprehension,
but CPython can't easily restrict the exception to that case
(as it doesn't know the target variable names when visiting
the outermost iterator expression)
(cherry picked from commit 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78)
|
|
|
|
|
|
|
|
|
| |
(GH-15320) (GH-15456)
Fix compilation of "break" and "continue" in the
"finally" block when the corresponding "try" block
contains "return" with a non-constant value.
(cherry picked from commit ef61c524ddeeb56da3858b86e349e7288d68178e)
|
|
|
|
|
|
|
| |
improves decoding performance (GH-15083)
(cherry picked from commit 7ebdda0dbee7df6f0c945a7e1e623e47676e112d)
Co-authored-by: Steve Dower <steve.dower@python.org>
|
|
|
|
|
|
|
|
|
| |
pymalloc_alloc() now returns directly the pointer, return NULL on
memory allocation error.
allocate_from_new_pool() already uses NULL as marker for "allocation
failed".
(cherry picked from commit 18f8dcfa10d8a858b152d12a9ad8fa83b7e967f0)
|
|
|
|
|
|
|
| |
Fix the following warning with GCC 4.8.5:
Objects/obmalloc.c: warning: ‘no_sanitize_thread’ attribute directive ignored
(cherry picked from commit 7e479c82218450255572e3f5fa1549dc283901ea)
Co-authored-by: Hai Shi <shihai1992@gmail.com>
|
|
|
|
| |
(GH-13781) (#14782)
|
|
|
|
|
| |
(cherry picked from commit 53c214344038341ce86fcf7efa12dc33be9d5b45)
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
|
|
|
|
|
| |
(cherry picked from commit 988e6aa322fb61651812fa5a61ec73316c71b041)
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
|
| |
|
|
|
|
|
|
|
|
| |
PyCode_New as a compatibility wrapper (GH-13959) (#14505)
Add PyCode_NewEx to be used internally and set PyCode_New as a compatibility wrapper
(cherry picked from commit 4a2edc34a405150d0b23ecfdcb401e7cf59f4650)
Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>
|
|
|
|
|
| |
(cherry picked from commit 2a7d596f27b2342caf168a03c95ebf3b56e5dbbd)
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
|
|
|
|
|
|
|
|
|
| |
* The UTF-8 incremental decoders fails now fast if encounter
a sequence that can't be handled by the error handler.
* The UTF-16 incremental decoders with the surrogatepass error
handler decodes now a lone low surrogate with final=False.
(cherry picked from commit 894263ba80af4b7733c2df95b527e96953922656)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
|
|
|
|
|
| |
(cherry picked from commit a8b27e623d75377aabe50df27e97cab4e81a174a)
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
|
|
|
|
|
| |
(cherry picked from commit 2e9954d3472a23919b96323fcd5bb6c1d6927155)
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
|
|
|
|
|
| |
(cherry picked from commit ff6bb0aa95259413f359d42410526ff0b4dccfb7)
Co-authored-by: Paul Monson <paulmon@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
| |
Fix MSVC warning:
objects\codeobject.c(285): warning C4244: '=':
conversion from 'Py_ssize_t' to 'unsigned char',
possible loss of data
(cherry picked from commit 376ce9852eec4e97745c723f0dd0fe64383c6cd3)
Co-authored-by: Victor Stinner <vstinner@redhat.com>
|
|
|
|
|
|
|
| |
(GH-13965) (GH-13967)
(cherry picked from commit 1f11cf9521114447b3e32e2ac88f075ffaa37555)
Co-authored-by: Raymond Hettinger <rhettinger@users.noreply.github.com>
|
|
|
|
|
| |
(cherry picked from commit 1f9531764cc0f8dbca1d8f429d162dc28282f4b4)
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
|
|
|
|
|
|
|
| |
(GH-13860) (GH-13891)
(cherry picked from commit dc2476500d91082f0c907772c83a044bf49af279)
Co-authored-by: Zackery Spytz <zspytz@gmail.com>
|
|
|
|
|
|
| |
Fix this MSVC warning:
objects\codeobject.c(264): warning C4244: '=':
conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
|
|
|
|
|
|
| |
This patch implements per opcode cache mechanism, and use it in
only LOAD_GLOBAL opcode.
Based on Yury's opcache3.patch in bpo-26219.
|
|
|
| |
Apologies for the earlier hasty attempt.
|
| |
|
|
|
|
|
|
|
|
|
| |
assignments (GH-13496)
The main slot assignment loop is now if-else if ladder, making the
control flow clearer.
Based on suggestion by Victor Stinner in:
https://github.com/python/cpython/pull/10304/#issuecomment-491123026
|
|
|
|
| |
(GH-13758)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
arguments in the code object (GH-13726)
|
| |
|
|
|
|
|
| |
This adds a vector of "search fingers" so that usable_arenas can be kept in sorted order (by number of free pools) via constant-time operations instead of linear search.
This should reduce worst-case time for reclaiming a great many objects from O(A**2) to O(A), where A is the number of arenas. See bpo-37029.
|
|
|
|
| |
(GH-13695)
|
|
|
|
|
|
|
| |
If a type's __ipow__ method was implemented in C, attempting to use
the *modulo* parameter would cause crashes.
https://bugs.python.org/issue36379
|
|
|
|
|
|
|
|
|
| |
(GH-13464)
Automatically replace
tp_print -> tp_vectorcall_offset
tp_compare -> tp_as_async
tp_reserved -> tp_as_async
|
| |
|