Repository navigation
[mypyc] Fix crash on a property with another decorator - #22157
Merged
Merged
Conversation
JukkaL
pushed a commit
that referenced
this pull request
Oct 15, 2026
Fixes mypyc/mypyc#1244. mypyc crashed when a method of a native class overrode a decorated method and the native signatures differed, for example when the override narrows the return type, or when both methods are `async def` with the same annotations: ```python class Base: @Traced def get(self) -> object: return None class Sub(Base): def get(self) -> int: return 1 ``` ``` File "mypyc/irbuild/vtable.py", line 78, in specialize_parent_vtable defining_cls.glue_methods[(entry.cls, entry.name)], KeyError: (ClassIR(name=Base, ...), 'get') ``` The function below the decorator is stored in `ClassIR.methods`, so `compute_vtable()` gave it a vtable entry. `specialize_parent_vtable()` then treated an override with a different signature like an override of a native method and looked up a glue method. There is none: a decorated method isn't in `method_decls`, so `handle_ext_method()` doesn't generate glue for overrides of it. A decorated method doesn't need a vtable entry at all. It isn't declared as a native method, so compiled code only calls it through the Python API. Since #22157 that also holds for a property with another decorator. `compute_vtable()` now skips methods without a declaration. This generalizes the check added in #22121, which skipped only the undecorated function of a decorated override. The only other code that used those entries was the `__del__` lookup in `generate_class()`. It now uses `ClassIR.get_method()`, so a decorated `__del__` still gets a finalizer, and still runs through the decorator.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes mypyc/mypyc#1238.
mypy only rejects decorators on top of
@property, so it accepts a property like this:In a native class,
prepare_method_def()left the getter out ofmethod_decls, like any decorated method, but still setis_prop_getterandproperty_types. Readingc.pin compiled code then generated a nativeGetAttrwith no getter behind it, and the compiler crashed inemit_method_callwithKeyError: "'C' has no attribute 'p'". If nothing compiled read the property, the module compiled, but the method was missing from the type's method table, so the decorator was called with the property'sgetset_descriptorand its result replaced the property. Withlru_cachethe import failed (TypeError: the first argument must be callable).A getter with other decorators is now handled like other decorated methods.
handle_ext_method()applies the decorators, wraps the result withbuiltins.propertyand sets it on the class. Non-native classes already did this. The property isn't a native one, so compiled code reads it with a generic attribute lookup and coerces the result to the type mypy inferred, which is the decorated function's return type.@functools.cached_propertyover another decorator takes the same path.A setter for such a property would need the native setter exposed as a Python callable, so for now it's reported as an error instead of crashing:
@propertyover@abstractmethod,@overrideor@finalisn't affected, since mypy removes those from the decorator list.A decorated property that overrides a native property still fails like a decorated method that overrides a native method (mypyc/mypyc#767). This PR doesn't change that.