Fix compatibility checks for conditional function definitions using decorators

[brianschubert]

Fixes #17211, resolves this # TODO:

mypy/test-data/unit/check-functions.test

Lines 1486 to 1494 in e106dd7

	def dec(f) -> Callable[[int], None]: pass
	x = int()
	if x:
	def f(x: str) -> None: pass
	else:
	# TODO: Complain about incompatible redefinition
	@dec
	def f(): pass

Before

from typing import Callable

def dec(f: object) -> Callable[[int], None]: raise NotImplementedError

if int():
    def f(x: str) -> None: pass
else:
    @dec
    def f() -> None: pass  # uh oh! passes without error

After

from typing import Callable

def dec(f: object) -> Callable[[int], None]: raise NotImplementedError

if int():
    def f(x: str) -> None: pass
else:
    @dec
    def f() -> None: pass  # E: All conditional function variants must have identical signatures \
                           # N: Original: \
                           # N:     def f(x: str) -> None \
                           # N: Redefinition: \
                           # N:     def f(int, /) -> None

[hauntsaninja]

I think the changes to the overload tests don't look quite right. This is meant to support this feature: #12606

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

operator (https://github.com/canonical/operator)
+ ops/framework.py:601: error: Incompatible redefinition (redefinition with type "Callable[[Framework], FrameworkEvents]", original type "FrameworkEvents")  [misc]
+ ops/charm.py:1330: error: Incompatible redefinition (redefinition with type "Callable[[CharmBase], CharmEvents]", original type "CharmEvents")  [misc]

pandas (https://github.com/pandas-dev/pandas)
+ pandas/core/_numba/executor.py:90: error: Incompatible redefinition (redefinition with type "Callable[[ndarray[Any, Any], ndarray[Any, Any], ndarray[Any, Any], int, VarArg(Any)], Any]", original type "Callable[[ndarray[Any, Any], ndarray[Any, Any], int, int, VarArg(Any)], Any]")  [misc]

[hauntsaninja]

Primer hits look correct!

[brianschubert]

@hauntsaninja Thanks the quick review! I may be reading this wrong, but I think the feature from #12606 is still working correctly. It's only the "broken" / unsupported condition versions in testOverloadIfNestedFailure that now emit an extra error. The "correct" versions in testOverloadIfNestedOk pass with no new errors.

I'll take a look to see if I can avoid the new errors, though I'm guessing that may be hard for similar reasons to why those overloads currently emit E: Single overload definition, multiple required and Name "xyz" already defined errors.

I concur on the primer hits :-)

[hauntsaninja]

Ah sorry, I missed that! In that case, this looks great. Thanks for the fix!