-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[ty] Simplify Any | (Any & T)
to Any
#20593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
|
Lint rule | Added | Removed | Changed |
---|---|---|---|
invalid-argument-type |
104 | 1 | 178 |
possibly-missing-attribute |
0 | 1 | 81 |
unsupported-operator |
4 | 0 | 33 |
invalid-assignment |
0 | 0 | 17 |
invalid-return-type |
0 | 0 | 12 |
possibly-missing-implicit-call |
0 | 0 | 12 |
not-iterable |
0 | 0 | 4 |
unused-ignore-comment |
1 | 0 | 0 |
Total | 109 | 2 | 337 |
All the new ecosystem diagnostics look like new manifestations of astral-sh/ty#1248. I'm not sure why we weren't emitting them before (maybe some Overall I think this makes us produce simpler, more user-friendly types. |
if ty.is_equivalent_to(self.db, element_type) | ||
|| ty.is_subtype_of(self.db, element_type) | ||
|| ty.into_intersection().is_some_and(|intersection| { | ||
intersection.positive(self.db).contains(&element_type) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A more generalised solution here (that would also allow us to get rid of the separate is_equivalent_to
call -- so might be quite a bit faster?) would be to add a third type relation, UnionSimplification
(not sure what the best name would be really), which would sit in between TypeRelation::Subtyping
and TypeRelation::Assignability
. It would mostly behave the same way as subtyping (Any | int
would not be considered simplifiable to Any
), but Any <: Any
, (Any | int) <: (int | Any)
and (Any & str) <: Any
would all be considered true
under this type relation.
We still emit Todo for mapping over an intersection with negated elements, could be that? |
* main: (21 commits) [ty] Literal promotion refactor (#20646) [ty] Add tests for nested generic functions (#20631) [`cli`] Add conflict between `--add-noqa` and `--diff` options (#20642) [ty] Ensure first-party search paths always appear in a sensible order (#20629) [ty] Use `typing.Self` for the first parameter of instance methods (#20517) [ty] Remove unnecessary `parsed_module()` calls (#20630) Remove `TextEmitter` (#20595) [ty] Use fully qualified names to distinguish ambiguous protocols in diagnostics (#20627) [ty] Ecosystem analyzer: relax timeout thresholds (#20626) [ty] Apply type mappings to functions eagerly (#20596) [ty] Improve disambiguation of class names in diagnostics (#20603) Add the *The Basics* title back to CONTRIBUTING.md (#20624) [`playground`] Fix quick fixes for empty ranges in playground (#20599) Update dependency ruff to v0.13.2 (#20622) [`ruff`] Fix minor typos in doc comments (#20623) Update dependency PyYAML to v6.0.3 (#20621) Update cargo-bins/cargo-binstall action to v1.15.6 (#20620) Fixed documentation for try_consider_else (#20587) [ty] Use `Top` materializations for `TypeIs` special form (#20591) [ty] Simplify `Any | (Any & T)` to `Any` (#20593) ...
I think this may help reduce some of the fallout from #20368 by creating simpler types when we narrow unions
Test plan
QUICKCHECK_TESTS=1000000 cargo test --release -p ty_python_semantic -- --ignored types::property_tests::stable