Restore _GUARD_KEYS_VERSION in LOAD_ATTR specializations - #130
Conversation
|
Oh, this is interesting, and is going to need some changes to how we build things internally too. We end up generating the generated_cases.c.h from Meta Python 3.14 https://github.com/facebookincubator/cinder/tree/meta/3.14 where we've backported the upstream support for not needing the guards keys version. In addition to the backout here we'll need to update our internal syncing scripts too. Or maybe what's easier would be to update cinder-bytecodes.c to have the _GUARD_KEYS_VERSION inlined into the opcode and if it ifdef'd under META_PYTHON. |
@ddorian If you'd like to land the full fix for it I think we just need to add: |
Can you do the syncing and I rebase on top of it? |
|
I've rebased this here with all tests green: ddorian#3 Should I push the rebased version here? Are you still interested in this PR? |
Yes, push the rebased version here and we'll go ahead and import it! |
The 3.14 and 3.15 interpreters were missing the shared-keys version check in LOAD_ATTR_METHOD_WITH_VALUES and LOAD_ATTR_NONDESCRIPTOR_WITH_VALUES, so a warmed load site kept returning the cached class attribute after an instance stored the attribute through the type's shared keys. That is what breaks SQLAlchemy's deferred column loads in facebookincubatorgh-115. Meta Python invalidates the type version when shared keys change, so _GUARD_TYPE_VERSION covers it there; the dk_version check is under #ifndef META_PYTHON.
77b81d1 to
00d7e57
Compare
|
@DinoV pushed |
|
@DinoV has imported this pull request. If you are a Meta employee, you can view this in D118315962. |
|
Thanks for the PR! |
partial fix for #115