Skip to content
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

[red-knot] Ensure differently ordered unions and intersections are understood as equivalent even inside arbitrarily nested tuples #15740

Merged
merged 2 commits into from
Jan 25, 2025

Conversation

AlexWaygood
Copy link
Member

@AlexWaygood AlexWaygood commented Jan 25, 2025

Summary

On main, red-knot:

  • Considers P | Q equivalent to Q | P
  • Considered tuple[P | Q] equivalent to tuple[Q | P]
  • Considers tuple[P | tuple[P | Q]] equivalent to tuple[tuple[Q | P] | P]
  • ‼️ Does not consider tuple[tuple[P | Q]] equivalent to tuple[tuple[Q | P]]

The key difference for the last one of these is that the union appears inside a tuple that is directly nested inside another tuple.

This PR fixes this so that differently ordered unions are considered equivalent even when they appear inside arbitrarily nested tuple types.

Test Plan

  • Added mdtests that fails on main
  • Checked that all property tests continue to pass with this PR

@AlexWaygood AlexWaygood added the red-knot Multi-file analysis & type inference label Jan 25, 2025
@AlexWaygood AlexWaygood changed the title Add a failing test [red-knot] Ensure differently ordered unions and intersections are understood as equivalent even inside arbitrarily nested tuples Jan 25, 2025
Comment on lines -1157 to +1186
_ => self.is_fully_static(db) && other.is_fully_static(db) && self == other,
_ => self == other && self.is_fully_static(db) && other.is_fully_static(db),
Copy link
Member Author

Choose a reason for hiding this comment

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

we have a teeny tiny speedup on Codspeed, which I suspect is just due to the change on this line

@AlexWaygood AlexWaygood merged commit f85ea1b into main Jan 25, 2025
21 checks passed
@AlexWaygood AlexWaygood deleted the alex/nested-tuples branch January 25, 2025 16:39
dcreager added a commit that referenced this pull request Jan 27, 2025
* main:
  Run `cargo update` (#15769)
  [red-knot] Document public symbol type inferece (#15766)
  Update dawidd6/action-download-artifact action to v8 (#15760)
  Update NPM Development dependencies (#15758)
  Update pre-commit dependencies (#15756)
  Update dependency ruff to v0.9.3 (#15755)
  Update dependency mdformat-mkdocs to v4.1.2 (#15754)
  Update Rust crate uuid to v1.12.1 (#15753)
  Update Rust crate unicode-ident to v1.0.15 (#15752)
  Fix docstring in ruff_annotate_snippets (#15748)
  Update Rust crate insta to v1.42.1 (#15751)
  Update Rust crate clap to v4.5.27 (#15750)
  Add references to `trio.run_process` and `anyio.run_process` (#15761)
  [`ruff`] Do not emit diagnostic when all arguments to `zip()` are variadic (`RUF058`) (#15744)
  [red-knot] Ensure differently ordered unions are considered equivalent when they appear inside tuples inside top-level intersections (#15743)
  [red-knot] Ensure differently ordered unions and intersections are understood as equivalent even inside arbitrarily nested tuples (#15740)
  [red-knot] Promote the `all_type_pairs_are_assignable_to_their_union` property test to stable (#15739)
  [`pylint`] Do not trigger `PLR6201` on empty collections (#15732)
  Improve the file watching failure error message (#15728)
  Speed symbol state merging back up (#15731)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants