You need to merge/rebase and fix conflicts now.

skip news because this really goes together with#11841, it's not a separate issue.

You need to merge/rebase and fix conflicts now.

Done

I'm not sure it's safe to change the meaning of the old macros.@benjaminp@serhiy-storchaka What do you think?

I'm not sure it's safe to change the meaning of the old macros.

They are already changed as part of#11841. This is just changing them in a safer way.

AFAICT,Py_TRASHCAN_SAFE_BEGIN wasn't changed in#11841 (though it was implemented differently).

I see what you mean. Let me be very precise what this PR will fix and what it will break, hopefully clarifying things:

This willfix a crash in this case:

1. classX usesPy_TRASHCAN_SAFE_BEGIN in its deallocator
2. a classY inherits fromX
3. a 50 levels deep nested instance ofY is deallocated

This willadd a new crash in this case:

1. classX usesPy_TRASHCAN_SAFE_BEGIN in its deallocator
2. classX does not inherit directly fromobject, but from another base class
3. a very deeply nested instance ofX is deallocated, where this nesting does not involve any other trashcan-using class liketuple orlist

I consider the first set of conditions more likely than the second, so this will fix more crashes than it introduces. But I cannot deny the possibility that it will break stuff.

Closing in favor ofGH-27693. SeeBPO-44874 and the linked mailing list thread for details.