Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[ty] Follow aliases when resolving stub mappings#25328

Merged
charliermarsh merged 2 commits into
mainfrom
micha/follow-aliases-when-resolving-stub-mappings
May 23, 2026
Merged

[ty] Follow aliases when resolving stub mappings#25328
charliermarsh merged 2 commits into
mainfrom
micha/follow-aliases-when-resolving-stub-mappings

Conversation

@MichaReiser

@MichaReiser MichaReiser commented May 22, 2026

Copy link
Copy Markdown
Member

Summary

map_stub_definition maps a stub definition to its "real-definition" (the same definition in a py file. This PR extends this mapping by resolving aliases. For:

main.py:

from a import bar

bar

a/__init__.pyi:

def bar() -> None: ...

a/__init__.py:

from .b import bar as bar

a/b.py:

def bar() -> None:
    """Implementation docstring"""

Playground

Clicking on bar in main.py performs the following step:

  1. Resolve bar to from a import bar in main.py
  2. Follow the import to a/__init__.pyi where it finds def bar()
  3. map_stub_definition now tries to map bar to its implementation. It finds the from .b import bar as bar in a/__init__.py and stops here

The step that is missing, and this PR adds, is that stub mapping must follow the import to the symbol's real definition.

The same applies when resolving documentation: ty first tries to get the documentation from the stub. If that's missing, ty tries to resolve the documentation from the implementation. However, that requires resolving the import, because the import itself has no docstring.

Closes astral-sh/ty#2150

@MichaReiser MichaReiser added server Related to the LSP server ty Multi-file analysis & type inference labels May 22, 2026
@astral-sh-bot

astral-sh-bot Bot commented May 22, 2026

Copy link
Copy Markdown

Typing conformance results

No changes detected ✅

Current numbers
The percentage of diagnostics emitted that were expected errors held steady at 89.52%. The percentage of expected errors that received a diagnostic held steady at 86.99%. The number of fully passing files held steady at 90/134.

@astral-sh-bot

astral-sh-bot Bot commented May 22, 2026

Copy link
Copy Markdown

Memory usage report

Memory usage unchanged ✅

@astral-sh-bot

astral-sh-bot Bot commented May 22, 2026

Copy link
Copy Markdown

ecosystem-analyzer results

Lint rule Added Removed Changed
not-iterable 0 0 1
Total 0 0 1

Raw diff:

dd-trace-py (https://github.com/DataDog/dd-trace-py)
- ddtrace/contrib/internal/subprocess/patch.py:321:44 error[not-iterable] Object of type `list[Unknown] | None | list[str] | ... omitted 3 union elements` may not be iterable
+ ddtrace/contrib/internal/subprocess/patch.py:321:44 error[not-iterable] Object of type `list[Unknown] | None | list[str] | Unknown | list[_T@deque | str]` may not be iterable

Full report with detailed diff (timing results)

@charliermarsh charliermarsh merged commit 0909c7e into main May 23, 2026
93 of 94 checks passed
@charliermarsh charliermarsh deleted the micha/follow-aliases-when-resolving-stub-mappings branch May 23, 2026 17:45
anishgirianish pushed a commit to anishgirianish/ruff that referenced this pull request May 28, 2026
## Summary

`map_stub_definition` maps a stub definition to its "real-definition"
(the same definition in a `py` file. This PR extends this mapping by
resolving aliases. For:

`main.py`:

```py
from a import bar

bar
```

`a/__init__.pyi`:

```py
def bar() -> None: ...
```

`a/__init__.py`:

```py
from .b import bar as bar

```

`a/b.py`:

```py
def bar() -> None:
    """Implementation docstring"""
```

[Playground](https://play.ty.dev/f7255368-b291-4865-b4ca-6cac35a437e8)

Clicking on `bar` in `main.py` performs the following step:

1. Resolve `bar` to `from a import bar` in `main.py`
2. Follow the import to `a/__init__.pyi` where it finds `def bar()`
3. `map_stub_definition` now tries to map `bar` to its implementation.
It finds the `from .b import bar as bar` in `a/__init__.py` and **stops
here**


The step that is missing, and this PR adds, is that stub mapping must
follow the import to the symbol's real definition.


The same applies when resolving documentation: ty first tries to get the
documentation from the stub. If that's missing, ty tries to resolve the
documentation from the implementation. However, that requires resolving
the import, because the import itself has no docstring.


Closes astral-sh/ty#2150
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

server Related to the LSP server ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Docstrings for reexported functions do not fall back to implementation definition

2 participants