[ty] Tighten up a few edge cases in Concatenate type-expression parsing#24172
[ty] Tighten up a few edge cases in Concatenate type-expression parsing#24172AlexWaygood merged 10 commits intomainfrom
Concatenate type-expression parsing#24172Conversation
Typing conformance resultsThe percentage of diagnostics emitted that were expected errors held steady at 87.72%. The percentage of expected errors that received a diagnostic held steady at 82.85%. The number of fully passing files held steady at 74/132. SummaryHow are test cases classified?Each test case represents one expected error annotation or a group of annotations sharing a tag. Counts are per test case, not per diagnostic — multiple diagnostics on the same line count as one. Required annotations (
True positives changed (4)4 diagnostics
|
Memory usage reportMemory usage unchanged ✅ |
ParamSpec type expression parsingParamSpec/Concatenate type expression parsing
ParamSpec/Concatenate type expression parsingParamSpec/Concatenate type-expression parsing
|
This comment was marked as outdated.
This comment was marked as outdated.
ParamSpec/Concatenate type-expression parsingConcatenate type-expression parsing
4dccb3a to
a145edc
Compare
|
Thanks for the review, you raised some great points! I've revised the approach, and also added snapshots to make it easier to see what the diagnostics in the various error cases will actually look like |
…sing (#24172) ## Summary There were: - a couple of places where we emitted two diagnostics where one would do - a few places where we fell back to overly precise inferred types in error cases (inferring types like `(Unknown, /) -> None` where `(...) -> None` would arguably be better) - a few places where we correctly emitted a diagnostic, but didn't have an ideal error message This PR just makes some minor cleanups in that area ## Test Plan new mdtests
Summary
There were:
(Unknown, /) -> Nonewhere(...) -> Nonewould arguably be better)This PR just makes some minor cleanups in that area
Test Plan
new mdtests