[ty]: make possibly-missing-attribute ignored by default#23918
[ty]: make possibly-missing-attribute ignored by default#23918oconnor663 merged 2 commits intomainfrom
possibly-missing-attribute ignored by default#23918Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 85.29%. The percentage of expected errors that received a diagnostic held steady at 78.13%. The number of fully passing files held steady at 64/132. |
Memory usage reportMemory usage unchanged ✅ |
carljm
left a comment
There was a problem hiding this comment.
Needs a cargo dev generate-all, but otherwise looks good.
|
Do we know why mypy_primer timed out? |
MichaReiser
left a comment
There was a problem hiding this comment.
We should explicitly enable the rule for our mypy primer runs here
This should also fix the mypy primer timeout
|
@MichaReiser done, thanks for the tip. Was the timeout just because the diagnostics diff was too large? |
Oh that could definitely be it! You could try running ecosystem-analyzer to be sure — I think its diffing logic has less pathological performance than mypy_primer IIRC? |
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
possibly-missing-submodule |
1,488 | 0 | 0 |
possibly-missing-attribute |
0 | 1,481 | 0 |
invalid-await |
0 | 40 | 0 |
unused-type-ignore-comment |
0 | 2 | 0 |
invalid-return-type |
0 | 1 | 0 |
| Total | 1,488 | 1,524 | 0 |
|
Hmm even with the config change mypy primer times out still. Any chance that's expected with ~1500 diagnostics switched around? (Aside: all the small ecosystem changes are flakes according to ecosystem analyzer.) |
Yes, it is — since ecosystem-analyzer passed without reporting any timeouts, I don't think you need to worry about it :-) it's just a huge diff that's too much for Python's stdlib difflib module, which doesn't have a great time complexity for pathological inputs |
This warning has a lot of false positives, and other typecheckers don't report it. The previous commit split out `possibly-missing-submodule` as a separate default-on warning, which was our last blocker for disabling this one.
bf72926 to
55fc4e4
Compare
Fixes astral-sh/ty#2244. Two commits in this PR:
[ty]: split out
possibly-missing-submodulefrompossibly-missing-attribute[ty]: make
possibly-missing-attributeignored by defaultThis warning has a lot of false positives, and other typecheckers don't
report it. The previous commit split out
possibly-missing-submoduleasa separate default-on warning, which was our last blocker for disabling
this one.
Example
foo.py:bar/__init__.py:bar/baz.pyis just an empty file.Before this PR we have
possibly-missing-attributeon both accesses:After this PR the variable access doesn't get a diagnostic, and we have
possibly-missing-submoduleon the module access: