Conversation
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-argument-type |
5 | 10 | 49 |
invalid-assignment |
0 | 0 | 5 |
invalid-return-type |
0 | 0 | 5 |
type-assertion-failure |
0 | 0 | 2 |
| Total | 5 | 10 | 61 |
|
(merging despite the macOS failure which is a known flaky test; we had a green build on macOS on a previous commit and only changed formatting) |
| if matches!( | ||
| CodeGeneratorKind::from_class(db, self, specialization), | ||
| Some(CodeGeneratorKind::DataclassLike(_)) | ||
| ) { |
There was a problem hiding this comment.
I think maybe ideally we'd have had a TODO here to change it back? I think it's buggy right now that self.dataclass_params isn't necessarily Some for all dataclasses, and we should fix that. (Unless I'm missing something.)
There was a problem hiding this comment.
I agree that the APIs here are far from ideal, but CodeGeneratorKind::from_class(…) is really supposed to be the function to check if something is dataclass-like. ClassLiteral::dataclass_params will not (and can not) be "eagerly" set in all cases during the first type inference pass. For a base-class based transformer, we do not discover any dataclass-parameters when inferring the type for the class. We can only discover them later, when we are able to iterate its MRO.
We should definitely work on improving this, though. At the very least, we should properly document what ClassLiteral::dataclass_params represents (dataclass parameters that are attached to this specific class, the absence of which does not mean that this class can not later be recognized as dataclass-like).
See also: astral-sh/ty#1835
Summary
This contains two bug fixes:
**kwargsDataclassInstancecloses astral-sh/ty#1987
Test Plan