-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-94822: Don't specialize when metaclasses are involved #94892
Conversation
Thanks for the quick fix. I think this LGTM. IIRC speaking to Mark at EuroPython he had other ideas about this though (something about just blocking non-immutable classes IIRC). Let's wait for his reply on Monday. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding all the extra tests.
Would it make sense to add a function to test.support, so we can replace
for _ in range(1025):
can be replaced with for _ in test.support.UntilSpecialized():
?
@@ -945,6 +945,10 @@ specialize_class_load_attr(PyObject *owner, _Py_CODEUNIT *instr, | |||
PyObject *name) | |||
{ | |||
_PyLoadMethodCache *cache = (_PyLoadMethodCache *)(instr + 1); | |||
if (!PyType_CheckExact(owner) || _PyType_Lookup(Py_TYPE(owner), name)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could safely generalize this to any immutable metaclass.
Py_TYPE(owner)->tp_flags & Py_TPFLAGS_IMMUTABLETYPE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, you're only referring to the PyType_CheckExact
call, right? The _PyType_Lookup
call stays?
Wouldn't we also need to add something like Py_TYPE(owner)->tp_getattro == PyType_Type.tp_getattro
too to protect against immutable types that define __getattribute__
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, you're only referring to the PyType_CheckExact call, right?
Yes
Wouldn't we also need to add something like Py_TYPE(owner)->tp_getattro == PyType_Type.tp_getattro too
And probably some other special case I've forgotten.
Let's just stick with the PyType_CheckExact(owner)
to be on the safe side.
Thanks @brandtbucher for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry, @brandtbucher, I could not cleanly backport this to |
…pythonGH-94892). (cherry picked from commit daf68ba) Co-authored-by: Brandt Bucher <[email protected]>
GH-94980 is a backport of this pull request to the 3.11 branch. |
…4892) (GH-94980) (cherry picked from commit daf68ba) Co-authored-by: Brandt Bucher <[email protected]>
This patch changes
LOAD_ATTR_CLASS
to fail if the class has a metaclass other thantype
, or if the named attribute is present ontype
itself. It also adds a bunch of regression tests for nasty edge-cases when caching class attributes and methods.Supersedes #94863 (see #94863 (comment)).