Pyright: Maximum call stack size exceeded on hover over Python's Operator's logical functions

[tg137]

Describe the bug
When hovering over operator logical functions, in VS Code, a Pyright request fails and logs the following output:

[Error - 08:54:45] Request textDocument/hover failed.
  Message: Request textDocument/hover failed with message: Maximum call stack size exceeded
  Code: -32603

To Reproduce
Create a Python file containing the following:

import operator
operator.and_(True, False)

The error will occur both whilst typing out the second line (when you get to the and_) as well as when subsequently hovering over the and_ section of the line.

As far as I can tell, this happens with all of the logical operations in the operator module (see here: https://docs.python.org/3/library/operator.html)

Expected behavior
No errors are thrown and hover functionality works correctly.

VS Code extension or command-line
This is when running as a VSCode extension on version 1.1.93.

[erictraut]

@jakebailey, this appears to be a bug in the source mapper logic that maps symbols in "pyi" files to "py" files. The problem in this case is that findFunctionDeclarations is attempting to do a source map of the symbol and_ in the file operator.pyi. It then calls _findFunctionDeclration with the corresponding source file operator.py. There are two declarations it finds for the symbol in this file. The first is a local function declaration (which is fine), but it also finds a declaration associated with a wildcard import from _operator. This resolves to the stub file _operator.pyi, which imports that symbol from operator.pyi. Infinite recursion results.

I can think of several solutions in the source mapper:

1. Pass a stack of source files that have been visited and perform an early-out return if you detect recursion.
2. Pass a simple recursion count and perform an early-out return if this grows beyond some max value.

The first is more complex but more precise. The latter is simpler but could result in unnecessary extra work and/or cut off legitimate searches sooner than necessary.

[jakebailey]

@bschnurr is working on a fix.

[erictraut]

This is addressed in Pyright 1.1.94, which I just published. It will also be included in this week's Pylance release.