-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[red-knot] simplify gradually-equivalent types out of unions and intersections #17467
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
|
|
Ecosystem results are mostly just changed types in existing error messages. There are a few new |
|
I think it makes sense to simplify As the mypy_primer hits on this PR demonstrate, it obviously isn't currently true that we infer I do think we should prioritise fixing the new ecosystem hits, though: we should be inferring |
* main: Update pre-commit dependencies (#17506) [red-knot] Simplify visibility constraint handling for `*`-import definitions (#17486) [red-knot] Detect (some) invalid protocols (#17488) [red-knot] Correctly identify protocol classes (#17487) Update dependency ruff to v0.11.6 (#17516) Update Rust crate shellexpand to v3.1.1 (#17512) Update Rust crate proc-macro2 to v1.0.95 (#17510) Update Rust crate rand to v0.9.1 (#17511) Update Rust crate libc to v0.2.172 (#17509) Update Rust crate jiff to v0.2.9 (#17508) Update Rust crate clap to v4.5.37 (#17507) Update astral-sh/setup-uv action to v5.4.2 (#17504) Update taiki-e/install-action digest to 09dc018 (#17503) [red-knot] infer attribute assignments bound in comprehensions (#17396) [red-knot] simplify gradually-equivalent types out of unions and intersections (#17467) [red-knot] pull primer projects to run from file (#17473)
Summary
If two types are gradually-equivalent, that means they share the same set of possible materializations. There's no need to keep two such types in the same union or intersection; we should simplify them.
Fixes #17465
The one downside here is that now we will simplify e.g.
Unknown | Todo(...)to justUnknown, ifUnknownwas added to the union first. This is correct from a type perspective (they are equivalent types), but it can mean we lose visibility into part of the cause for the type inferring as unknown. I think this is OK, but if we think it's important to avoid this, I can add a special case to try to preserveTodooverUnknown, if we see them both in the same union or intersection.Test Plan
Added and updated mdtests.