[ty] Detect invalid attempts to instantiate abstract classes#22898
[ty] Detect invalid attempts to instantiate abstract classes#22898AlexWaygood wants to merge 2 commits intomainfrom
Conversation
Typing conformance results improved 🎉The percentage of diagnostics emitted that were expected errors increased from 79.63% to 79.71%. The percentage of expected errors that received a diagnostic increased from 70.86% to 71.23%. Summary
True positives addedDetails
|
|
ce9fc32 to
e0c7af0
Compare
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
call-non-callable |
1,029 | 0 | 0 |
invalid-return-type |
0 | 4 | 4 |
invalid-assignment |
4 | 0 | 1 |
invalid-argument-type |
2 | 0 | 1 |
unused-ignore-comment |
0 | 3 | 0 |
| Total | 1,035 | 7 | 6 |
sounds like that one might be intentional, idk |
CodSpeed Performance ReportMerging this PR will not alter performanceComparing Summary
Footnotes
|
b19b967 to
7b05b07
Compare
86f5ce8 to
ee7a9ac
Compare
Ecosystem analysis (WIP)
|
c9ef28e to
f3f7bd1
Compare
f3f7bd1 to
c6add40
Compare
023dc3a to
84ff2c1
Compare
c6add40 to
9fe24aa
Compare
9fe24aa to
89a1fcc
Compare
…3376) ## Summary Another PR split out from #22898, to reduce the diff in that PR. Changes made here: - Use "declared" rather than "defined" in a diagnostic message - Use secondary annotations (underlined with `______`) rather than primary annotations (underlined with `^^^^^^^`) for annotations in informational subdiagnostics - Shorten one diagnostic message in some situations: if the abstract method was defined on the same class that we're emitting a diagnostic on, just say "method X declared here" rather than "method X declared here on superclass Y" ## Test Plan `cargo insta test -p ty_python_semantic`
89a1fcc to
81a682a
Compare
…ns when determining whether an abstract method has been overridden in a subclass
allow abstract methods to be overridden by synthesized methods return a ref from the tracked function add cycle handling truncate the list of abstractmethods by default try to reduce memory usage add more docs
81a682a to
eac38c8
Compare
…ns when determining whether an abstract method has been overridden in a subclass (#23381) ## Summary This is another standalone PR pulled out of #22898, to reduce the diff on that PR. Currently we emit a false-positive `abstract-method-in-final-class` diagnostic on this class, because we do not see that the synthesized `__lt__` method created by `@dataclass(order=True)` has overridden the abstract `__lt__` method from the class's superclass: ```py from abc import ABC, abstractmethod from dataclasses import dataclass from typing import final class AbstractOrdered(ABC): @AbstractMethod def __lt__(self, other): ... @Final @DataClass(order=True) class ConcreteOrdered(AbstractOrdered): ... ``` We also currently do not recognise `ClassVar` declarations in a subclass as overriding an abstract method/property on a base class. While an annotation without a binding is not sufficient at runtime as an abstract method override, the `ClassVar` qualifier serves as an explicit declaration from the user to the type checker that the attribute will be accessible on the class object itself (not simply instances of the class) at runtime. We therefore choose to treat `ClassVar` declarations as overrides of abstract methods from superclasses. ## Test Plan mdtests updated/extended
btw: There is a recent discussion about semantics of abstractmethod on classes that don't have ABC as metaclass. |
Summary
Closes astral-sh/ty#1877
Test Plan