ruff
7bf50e70 - [ty] Generics: Respect typevar bounds when matching against a union (#21893)

Commit
3 days ago
[ty] Generics: Respect typevar bounds when matching against a union (#21893) ## Summary Respect typevar bounds and constraints when matching against a union. For example: ```py def accepts_t_or_int[T_str: str](x: T_str | int) -> T_str: raise NotImplementedError reveal_type(accepts_t_or_int("a")) # ok, reveals `Literal["a"]` reveal_type(accepts_t_or_int(1)) # ok, reveals `Unknown` class Unrelated: ... # error: [invalid-argument-type] "Argument type `Unrelated` does not # satisfy upper bound `str` of type variable `T_str`" accepts_t_or_int(Unrelated()) ``` Previously, the last call succeed without any errors. Worse than that, we also incorrectly solved `T_str = Unrelated`, which often lead to downstream errors. closes https://github.com/astral-sh/ty/issues/1837 ## Ecosystem impact Looks good! * Lots of removed false positives, often because we previously selected a wrong overload for a generic function (because we didn't respect the typevar bound in an earlier overload). * We now understand calls to functions accepting an argument of type `GenericPath: TypeAlias = AnyStr | PathLike[AnyStr]`. Previously, we would incorrectly match a `Path` argument against the `AnyStr` typevar (violating its constraints), but now we match against `PathLike`. ## Performance Another regression on `colour`. This package uses `numpy` heavily. And `numpy` is the codebase that originally lead me to this bug. The fix here allows us to infer more precise `np.array` types in some cases, so it's reasonable that we just need to perform more work. The fix here also requires us to look at more union elements when we would previously short-circuit incorrectly, so some more work needs to be done in the solver. ## Test Plan New Markdown tests
Author
Parents
Loading