Skip to content

Conversation

@carljm
Copy link
Contributor

@carljm carljm commented Apr 22, 2025

Summary

#17451 was incomplete. AlwaysFalsy and AlwaysTruthy are not the only two types that are super-types of some literals (of a given kind) and not others. That set also includes intersections containing AlwaysTruthy or AlwaysFalsy, and intersections containing literal types of the same kind. Cover these cases as well.

Fixes #17478.

Test Plan

Added mdtests.

QUICKCHECK_TESTS=1000000 cargo test -p red_knot_python_semantic -- --ignored types::property_tests::stable failed on both all_fully_static_type_pairs_are_subtypes_of_their_union and all_type_pairs_are_assignable_to_their_union prior to this PR, passes after it.

@carljm carljm added the ty Multi-file analysis & type inference label Apr 22, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Apr 22, 2025

mypy_primer results

No ecosystem changes detected ✅

Copy link
Member

@AlexWaygood AlexWaygood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I also confirmed locally that the property tests are no longer flaky (ran them with 2,000,000 iterations 😄)

/// Return `true` if this type can be a supertype of some literals of `kind` and not others.
fn splits_literals(self, db: &'db dyn Db, kind: LiteralKind) -> bool {
match self {
Type::AlwaysFalsy | Type::AlwaysTruthy => true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm slightly concerned about how much special-casing we're adding for Type::AlwaysTruthy and Type::AlwaysFalsy, given that conceptually these are really just two protocol types, and we'll be adding a lot more protocol types to our model very soon... but I guess we (I) can cross that bridge when we (I) come to it :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think even with the addition of general protocol types, AlwaysTruthy and AlwaysFalsy will remain "special" in that I don't think any other protocol type can "distinguish" between literals of the same kind?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's hope so!!

@carljm carljm force-pushed the cjm/unionliterals branch from fe6f045 to f215474 Compare April 22, 2025 16:09
@carljm carljm enabled auto-merge (squash) April 22, 2025 16:10
@carljm carljm merged commit 27ada26 into main Apr 22, 2025
30 of 31 checks passed
@carljm carljm deleted the cjm/unionliterals branch April 22, 2025 16:12
dcreager added a commit that referenced this pull request Apr 23, 2025
* main: (28 commits)
  [red-knot] Make `BoundMethodType` a salsa interned (#17581)
  [red-knot] Emit a diagnostic if a non-protocol is passed to `get_protocol_members` (#17551)
  [red-knot] Add more tests for protocol members (#17550)
  [red-knot] Assignability for subclasses of `Any` and `Unknown` (#17557)
  [red-knot] mypy_primer: add strawberry, print compilation errors to stderr (#17578)
  [red-knot] GenericAlias instances as a base class (#17575)
  Remove redundant `type_to_visitor_function` entries (#17564)
  Fixes how the checker visits `typing.cast`/`typing.NewType` arguments (#17538)
  [red-knot] Class literal `__new__` function callable subtyping (#17533)
  [red-knot] Surround intersections with `()` in potentially ambiguous contexts (#17568)
  [minor] Delete outdated TODO comment (#17565)
  [red-knot] add regression test for fixed cycle panic (#17535)
  [red-knot] fix unions of literals, again (#17534)
  red_knot_python_semantic: remove last vestige of old diagnostics!
  red_knot_python_semantic: migrate `types` to new diagnostics
  red_knot_python_semantic: migrate `types/diagnostic` to new diagnostics
  red_knot_python_semantic: migrate `types/call/bind` to new diagnostics
  red_knot_python_semantic: migrate `types/string_annotation` to new diagnostics
  red_knot_python_semantic: migrate `types/infer` to new diagnostic model
  red_knot_python_semantic: migrate INVALID_ASSIGNMENT for inference
  ...
dcreager added a commit that referenced this pull request Apr 23, 2025
…var-instance

* dcreager/generic-constructor: (29 commits)
  We don't need this
  [red-knot] Make `BoundMethodType` a salsa interned (#17581)
  [red-knot] Emit a diagnostic if a non-protocol is passed to `get_protocol_members` (#17551)
  [red-knot] Add more tests for protocol members (#17550)
  [red-knot] Assignability for subclasses of `Any` and `Unknown` (#17557)
  [red-knot] mypy_primer: add strawberry, print compilation errors to stderr (#17578)
  [red-knot] GenericAlias instances as a base class (#17575)
  Remove redundant `type_to_visitor_function` entries (#17564)
  Fixes how the checker visits `typing.cast`/`typing.NewType` arguments (#17538)
  [red-knot] Class literal `__new__` function callable subtyping (#17533)
  [red-knot] Surround intersections with `()` in potentially ambiguous contexts (#17568)
  [minor] Delete outdated TODO comment (#17565)
  [red-knot] add regression test for fixed cycle panic (#17535)
  [red-knot] fix unions of literals, again (#17534)
  red_knot_python_semantic: remove last vestige of old diagnostics!
  red_knot_python_semantic: migrate `types` to new diagnostics
  red_knot_python_semantic: migrate `types/diagnostic` to new diagnostics
  red_knot_python_semantic: migrate `types/call/bind` to new diagnostics
  red_knot_python_semantic: migrate `types/string_annotation` to new diagnostics
  red_knot_python_semantic: migrate `types/infer` to new diagnostic model
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Daily property test run failed on Sat Apr 19 2025

3 participants