[ty] fix assigning a typevar to a union with itself#17910
Conversation
|
|
The primer results are identical to #17901 |
carljm
left a comment
There was a problem hiding this comment.
Looks good to me, thank you! I'd vaguely considered this option but didn't love adding special handling for unions and intersections outside of their dedicated arms -- but now that I see it worked through, it's really not bad at all. The DNF normalization really helps us here.
| @@ -1003,6 +1003,26 @@ impl<'db> Type<'db> { | |||
| self_typevar == other_typevar | |||
There was a problem hiding this comment.
This arm is removable because we (now, as of this PR) handle it in equivalence, which is already checked above.
There was a problem hiding this comment.
In fact, it was already handled prior to this PR in equivalence! The last branch of the match statement handles it in is_equivalent_to(); the if self == other check before the match handles it in is_gradual_equivalent_to. The branches that you and I both added in our separate PRs was redundant.
I added tests (as you suggested in https://github.com/astral-sh/ruff/pull/17910/files#r2077710287) that demonstrate this.
…lass * origin/main: [`pylint`] add fix safety section (`PLC2801`) (#17825) Add instructions on how to upgrade to a newer Rust version (#17928) [parser] Flag single unparenthesized generator expr with trailing comma in arguments. (#17893) [ty] Ensure that `T` is disjoint from `~T` even when `T` is a TypeVar (#17922) [ty] Sort collected diagnostics before snapshotting them in mdtest (#17926) [ty] Add basic file watching to server (#17912) Make completions an opt-in LSP feature (#17921) Add link to `ty` issue tracker (#17924) [ty] Add support for `__all__` (#17856) [ty] fix assigning a typevar to a union with itself (#17910) [ty] Improve UX for `[duplicate-base]` diagnostics (#17914) Clean up some Ruff references in the ty server (#17920)
Summary
This is an alternative PR to #17901. It retains the tests from that PR but uses a more targeted fix.
I don't think it's necessary to refactor the
Type::is_subtype_of()andType::is_assignable_to()methods to the extent that #17901 does. As far as I can see, the problem is specific to unions and intersections containingTypeVars. I don't think there's any situation where aTypeVarTcan be assignable to a typeSwithout its upper bound being assignable toSunlessSis a union that directly containsT; this is the premise that my alternative implementation is based on.I also added a couple more tests on top of the ones @carljm added.
Test Plan
cargo test -p ty_python_semanticCo-authored-by: Carl Meyer [email protected]