Mypy incorrectly infers that parameters are positional-only for `__eq__` methods autogenerated with `@dataclass`

[AlexWaygood]

For a class decorated with @dataclass, mypy assumes that the class's __eq__ method will have the exact same signature as object.__eq__. However, this is subtly incorrect. Whereas the signature of object.__eq__ is def __eq__(self, other: object, /) -> bool: ..., the signature of MyDataclass.__eq__ is def __eq__(self, other: object) -> bool: .... I.e., for the method auto-generated by @dataclass, the second argument is positional-or-keyword; whereas the second argument is positional-only for object.__eq__.

Minimal repro (using mypy 0.931, Python 3.10 -- try it on mypy playground here):

from dataclasses import dataclass

@dataclass
class Foo: ...

reveal_type(Foo.__eq__)  # Revealed type is "def (builtins.object, builtins.object) -> builtins.bool"

[AlexWaygood]

^FWIW, this isn't a purely theoretical issue. I'm writing a patch for stubtest, to increase its strictness when checking dunder methods. With my patch applied, stubtest complains that the __eq__ methods of pstats.FunctionProfile and pstats.StatsProfile in the typeshed stubs are inconsistent with their __eq__ methods at runtime, because the stub uses the @dataclass decorator (cc @sobolevn, @hauntsaninja)

[JelleZijlstra]

It looks like the issue is that we don't actually generate an __eq__ method for dataclasses, so we end up inheriting the one from object. This code instead just generates a TypeVar: https://github.com/python/mypy/blob/master/mypy/plugins/dataclasses.py#L171.

[AlexWaygood]

Adding the "priority-low" label, since further updates to stubtest mean that this is no longer much of an issue.