Make Binding::range() point to the range of a type parameter's name, not the full type parameter

[AlexWaygood]

Summary

A PEP-695 type parameter creates a binding that is tracked by Ruff's semantic model:

def f[S](): ...
    # ^ `S` symbol bound here

But if the type parameter has a bound or constraint, the range of the Binding recorded by Ruff's semantic model includes the bounds or constraints of the type parameter:

def f[T: int](): ...
    # ^^^^^^ Semantic model's `Binding` for `T` has this range

def g[U: (int, str)](): ...
    # ^^^^^^^^^^^^^ Semantic models' binding for `U` has this range

This is problematic, as S: int is not a valid Python identifier, and nor is T: (int, str). All other bindings in Ruff's semantic model have their range point to the name that is bound, not the full expression/statement that creates the binding. A specific effect that this has is that if you have a Binding x that points to a PEP-695 type parameter, calling x.name(source) does not actually return the name of the PEP-695 type parameter. Instead, if x pointed to the binding for T in the example above, calling x.name(source) would return "T: int", and if x pointed to the binding for U, calling x.name(source) would return "U: (int, str)".

This PR changes the range for PEP-695 bindings so that it points to the name that is bound by the type parameter. This makes these Bindings consistent with other bindings, makes Binding::name() work as expected in all situations, allows us to simplify some code in the implementation of the PYI019 rule, and unblocks #15862

Test Plan

cargo test -p ruff_linter --lib

Co-authored-by: Brent Westbrook 36778786+ntBre@users.noreply.github.com

[MichaReiser]

Haha nice find.

Do you expect that this breaks any diagnostic range? E.g. do you know if the binding range is used in any diagnostic / fix code? I know, this is probably hard to figure out, just something that I'm slightly worried about but relying on our tests/user reports might be fine to catch this.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

Do you expect that this breaks any diagnostic range?

It's very hard to tell... :(

E.g. do you know if the binding range is used in any diagnostic / fix code? I know, this is probably hard to figure out, just something that I'm slightly worried about but relying on our tests/user reports might be fine to catch this.

Agreed, and this is partly why I wanted to separate this out as a separate PR from #15862 (see my comment in #15862 (comment)). This is also why I worked around the bug in #15888 rather than fixing it prior to making that PR... but then @ntBre ran into exactly the same bug the next day in #15862! And I don't think it'll be so easy to workaround the bug in his PR. Plus, Binding::name() not working consistently for all bindings is a massive footgun. So I think it's time to fix the bug.

The fact that none of our snapshots change and the ecosystem check is clean gives me confidence that, if this does change our user-facing behaviour in some cases, they're at least rare/edge cases. And PEP-695 type parameters are anyway new syntax that are still rarely used in the real world. So I think we're good here.