Cannot determine type of function with too many redefinitions

[DiegoBaldassarMilleuno]

Describe the bug
If a function is (re)defined 17 or more times through a decorator and is invoked between the first and the last definition, pyright reports Type of "f" could not be determined because it refers to itself

Code or Screenshots

The following is a minimized version of a (believe it or not) real-world case, from a Jupyter notebook.
Note that reportRedeclaration is disabled globally, otherwise all definitions save for the last one would report an error.

Code spoiler

# pyright: reportRedeclaration=none
# mypy: disable-error-code="no-redef"

from collections.abc import Callable

def decorator(func: Callable[[], None]) -> Callable[[], None]:
    return func

@decorator
def f() -> None: return None  # 1

@decorator
def f() -> None: return None  # 2

@decorator
def f() -> None: return None  # 3

@decorator
def f() -> None: return None  # 4

@decorator
def f() -> None: return None  # 5

@decorator
def f() -> None: return None  # 6

@decorator
def f() -> None: return None  # 7

@decorator
def f() -> None: return None  # 8

f()  # Type of "f" could not be determined because it refers to itself [reportGeneralTypeIssues]

@decorator
def f() -> None: return None  # 9

@decorator
def f() -> None: return None  # 10

@decorator
def f() -> None: return None  # 11

@decorator
def f() -> None: return None  # 12

@decorator
def f() -> None: return None  # 13

@decorator
def f() -> None: return None  # 14

@decorator
def f() -> None: return None  # 15

@decorator
def f() -> None: return None  # 16

@decorator
def f() -> None: return None  # 17

A few notes:

• The error occurs as long as the call to f is anywhere after the first definition and before the last one; calling f after the last definition is ok
• Removing the last decorator makes the error disappear; removing any other is inconsequential.
• Adding f: Callable[[], None] before the first definition is also inconsequential.
• Could not replicate the same behavior in mypy, even with many more redefinitions
• This seems to be introduced in version 1.1.386

I suppose this is simply encountering some internal limits of pyright, but I thought it'd be better to let you know just in case, because this behavior seems slightly weird.

VS Code extension or command-line
Python version: 3.13.1
Pyright version: from 1.1.386 to 1.1.392; 1.1.385 reports no errors

[erictraut]

Thanks for the bug report — including the clear repro steps and version analysis.

This is caused by a performance optimization I added in 1.1.386. When pyright encounters a symbol with more than 16 type declarations (as in your example), it falls back on a cheaper but less-robust mechanism for evaluating its type. Prior to this optimization, there were cases that resulted in pathological slow-downs and hangs.

An unanticipated side effect of the less-robust mechanism is that it can result in false positive detection of recursive type definitions under a rare set of circumstances, which explains the error you're seeing here.

To address the bug, I considered simply increasing the threshold from 16 to 32, but this isn't very satisfying because it would simply move the point where the bug occurs. I decided instead to suppress any recursive type definition errors in this case. This will be included in the next release.