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

Skip to content

[ty] Display docs for matching parameter when hovering over the name of an argument passed by keyword.#25283

Merged
lerebear merged 1 commit into
mainfrom
lerebear/push-qzqluswmuxrw
May 27, 2026
Merged

[ty] Display docs for matching parameter when hovering over the name of an argument passed by keyword.#25283
lerebear merged 1 commit into
mainfrom
lerebear/push-qzqluswmuxrw

Conversation

@lerebear

@lerebear lerebear commented May 20, 2026

Copy link
Copy Markdown
Contributor

Summary

This makes it so that hovering over the name of an argument passed by keyword shows the matching parameter label and documentation rather than the inferred type of the argument value:

def test(ab: int):
    """my cool test

    Args:
        ab: a nice little integer
    """
    return 0

test(ab=123)
      ^
(parameter) ab: int
---------------------------------------------
a nice little integer

Two additional notes on this new behaviour:

  • For a parameter without any documentation, we will show just the parameter label: (parameter) ab: int.
  • We will also show the documentation for a variadic keyword parameter (i.e., **kwargs) when the argument name maps to that type of parameter.

By contrast, nothing changes when hovering over the argument value: it will continue to show the inferred type of the value:

value = 123

def test(ab: int):
    """my cool test

    Args:
        ab: a nice little integer
    """
    return 0

test(ab=value)
          ^
Literal[123]

Closes astral-sh/ty#1350.
Closes astral-sh/ty#3538.

Test Plan

Please see included tests.

@astral-sh-bot astral-sh-bot Bot added server Related to the LSP server ty Multi-file analysis & type inference labels May 20, 2026
@lerebear lerebear force-pushed the lerebear/push-qzqluswmuxrw branch 2 times, most recently from 689d747 to f20d2dd Compare May 21, 2026 21:01
@lerebear lerebear force-pushed the lerebear/push-qzqluswmuxrw branch 2 times, most recently from 19392c3 to adf04b1 Compare May 21, 2026 21:48
@lerebear lerebear marked this pull request as ready for review May 21, 2026 22:03
@astral-sh-bot astral-sh-bot Bot requested a review from dhruvmanila May 21, 2026 22:03
@MichaReiser

MichaReiser commented May 22, 2026

Copy link
Copy Markdown
Member

I only skimmed the code, but I wonder whether this works with overloads where the parameter is only documented in the implementation? Can you also say a little more on the taken implementation approach for the argument/parameter "matching"? Like what was your thinking behind adding a new matching vs extending keyword_argument_names (not suggesting that this would be a good idea)?

@MichaReiser

MichaReiser commented May 26, 2026

Copy link
Copy Markdown
Member

Related (but also somewhat different) astral-sh/ty#3538

@Gankra Gankra left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable to me. I'm a bit curious if there's rendering issues with multiline argument docstrings, but I'll assume since this is already using existing machinery that those concerns were addressed.


fn parameter_hover_label(label: &str, is_keyword_variadic: bool) -> String {
let kind = if is_keyword_variadic {
"variadic keyword parameter"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit of a mouthful?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but on the other hand it is accurate and helps explain the difference between the name of the parameter and the name of the hover target in this case. Can you think of another way to express the same idea? Or would you prefer that we didn't try and just left this as plain "parameter"?

I won't block on this, but I will plan to address this in a follow-up if you have further thoughts.

@lerebear

Copy link
Copy Markdown
Contributor Author

I wonder whether this works with overloads where the parameter is only documented in the implementation?

Yes it does, because it reuses the existing doc lookup helpers (which already handle that type of fallback). For the same reason however, it does not handle the edge case where the overload contains a general docstring but only the implementation contains parameter specific docs: in that case we will show the parameter information from the selected overload but no docs. I think that's acceptable as a first pass, but in the future we might consider a further, parameter-specific extension to doc lookup.

I will add a few regression tests to demonstrate these behaviours.

Can you also say a little more on the taken implementation approach for the argument/parameter "matching"? Like what was your thinking behind adding a new matching vs extending keyword_argument_names?

I'm not sure what you mean by keyword_argument_names: could you please clarify?

I see an adjacent concept called argument_names in our inlay hints code, but that only covers bare positional arguments (skips positional arguments that are passed by keyword, and also skips **kwargs), and it would still need to be extended with docstring lookup. As a result those use cases feel different enough to warrant a different approach.

@lerebear

Copy link
Copy Markdown
Contributor Author

I'm a bit curious if there's rendering issues with multiline argument docstrings, but I'll assume since this is already using existing machinery that those concerns were addressed.

Yes, precisely.

@lerebear

Copy link
Copy Markdown
Contributor Author

Related (but also somewhat different) astral-sh/ty#3538

I think that issue will also be addressed by this PR: hovering over the argument name will show both parameter info (as requested) and docs, and hovering over the argument value will still display inferred type information.

@lerebear lerebear force-pushed the lerebear/push-qzqluswmuxrw branch from adf04b1 to 436728c Compare May 27, 2026 18:33
@lerebear lerebear merged commit 4a7ca06 into main May 27, 2026
52 checks passed
@lerebear lerebear deleted the lerebear/push-qzqluswmuxrw branch May 27, 2026 18:59
anishgirianish pushed a commit to anishgirianish/ruff that referenced this pull request May 28, 2026
…of an argument passed by keyword. (astral-sh#25283)

<!--
Thank you for contributing to Ruff/ty! To help us out with reviewing,
please consider the following:

- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title? (Please prefix
with `[ty]` for ty pull
  requests.)
- Does this pull request include references to any relevant issues?
- Does this PR follow our AI policy
(https://github.com/astral-sh/.github/blob/main/AI_POLICY.md)?
-->

## Summary

<!-- What's the purpose of the change? What does it do, and why? -->

This makes it so that hovering over the name of an argument passed by
keyword shows the matching parameter label and documentation rather than
the inferred type of the argument value:

```py
def test(ab: int):
    """my cool test

    Args:
        ab: a nice little integer
    """
    return 0

test(ab=123)
      ^
```

````txt
(parameter) ab: int
---------------------------------------------
a nice little integer
````

Two additional notes on this new behaviour:
- For a parameter without any documentation, we will show just the
parameter label: `(parameter) ab: int`.
- We will also show the documentation for a variadic keyword parameter
(i.e., `**kwargs`) when the argument name maps to that type of
parameter.

By contrast, nothing changes when hovering over the argument value: it
will continue to show the inferred type of the value:

```py
value = 123

def test(ab: int):
    """my cool test

    Args:
        ab: a nice little integer
    """
    return 0

test(ab=value)
          ^
```

````txt
Literal[123]
````

Closes astral-sh/ty#1350.
Closes astral-sh/ty#3538.

## Test Plan

Please see included tests.

<!-- How was it tested? -->
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.

Hover over a function call's parameters should show type definition, not type of passed value On-hover for call arguments

4 participants