Report super() in a directly-defined NamedTuple method#3845
Conversation
This comment has been minimized.
This comment has been minimized.
| errors, | ||
| range, | ||
| ErrorKind::InvalidSuperCall, | ||
| "`super` call with no arguments is not allowed in a `NamedTuple` method; it raises a `RuntimeError` when the class is defined".to_owned(), |
There was a problem hiding this comment.
just "super call with no arguments is not allowed in a NamedTuple method" is enough, I don't think the latter part contains info that helps the user fix the issue
There was a problem hiding this comment.
Done — dropped the trailing clause; the message is now just "`super` call with no arguments is not allowed in a `NamedTuple` method".
yangdanny97
left a comment
yangdanny97
left a comment
There was a problem hiding this comment.
LGTM aside from one comment
@NathanTempest if you get around to merging this, maybe you can patch it to address the comment since it's small?
| /// If true, the namedtuple fields were dynamically generated (e.g., using a | ||
| /// generator or variable) and couldn't be statically resolved. | ||
| pub has_dynamic_fields: bool, | ||
| /// True if this class directly subclasses `NamedTuple` (so it is built by the NamedTuple |
There was a problem hiding this comment.
I think we can leave it at "Does this class directly extend NamedTuple?"
There was a problem hiding this comment.
Done — simplified the doc comment to "Does this class directly extend NamedTuple?".
A zero-argument `super()` inside a method of a class that directly subclasses `NamedTuple` makes the class fail to define at runtime: the compiler creates a `__class__` cell for `super()`, but the NamedTuple machinery does not propagate `__classcell__` to `type.__new__`, raising `RuntimeError`. Subclasses of a concrete NamedTuple are built by ordinary class machinery and are unaffected. Record whether a NamedTuple is directly defined (vs inherited) in its metadata, and emit an `InvalidSuperCall` error for a no-argument `super()` resolved inside a directly-defined NamedTuple method. Closes facebook#3763
markselby9
force-pushed
the
feat/3763-super-namedtuple
branch
from
aebace2 to
7909f37
Compare
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
3 participants
Closes #3763.
Summary
A zero-argument
super()inside a method of a class that directly subclassesNamedTuplemakes the class fail to define at runtime: the compiler creates a__class__cell forsuper(), but theNamedTuplemachinery does not propagate__classcell__totype.__new__, raisingRuntimeError. Subclasses of a concreteNamedTupleare built by ordinary class machinery and are unaffected.This records whether a
NamedTupleis directly defined (vs. inherited) in its metadata and emits aninvalid-super-callerror for a no-argumentsuper()resolved inside a directly-definedNamedTuplemethod.Note: only the zero-argument form is detected. An explicit
super(F, self)fails at runtime for the same reason, but the lexical enclosing class is not threaded into the explicit-args binding, so it is not flagged yet (documented with abug=test).Test Plan
New tests in
pyrefly/lib/test/named_tuple.rs:super(),super().__repr__(), and classmethodsuper()in a directNamedTupleare flagged; (deep) subclasses and methods withoutsuper()are not; explicitsuper(F, self)is tracked as a known gap.cargo testpasses; full lib test suite is green.