Conversation
I decided to split out the addition of these tests from other PRs so that it's easier to follow changes to the LSP's function call handling
Gankra
requested review from
AlexWaygood,
MichaReiser and
sharkdp
as code owners
|
(Each of the 4 files received a copy of the same 6 tests) |
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
| "mymodule.py", | ||
| r#" | ||
| def ab(a): | ||
| """the real implementation!""" | ||
| "#, | ||
| ) |
There was a problem hiding this comment.
Should this have the overloads defined so that the test asserts that goto definition goes to the correct overload? I'm fine with it not being present, I mainly want to understand the reasoning behind the test cases in this file as they all have defined only the implementation.
There was a problem hiding this comment.
Hmm interesting, would you expect a .pyi and a .py to declare overloads? (they're purely type annotations right? there isn't an implementation to go to for an overload? or did I get myself mixed up)
There was a problem hiding this comment.
Hmm, yeah that's a good point. It's not required for the overload definitions to be present in both runtime and stub files as they're mainly for typing purposes (as you've stated as well). So, I think my main question would be do we want to test the goto definition functionality by defining the overloads in the runtime file?
There was a problem hiding this comment.
I think ultimately goto-definition just has boring answers here, but it's worth making sure stub mapping doesn't get confused by the situation (that said it's possible we want like, 3 different variations of every one of these tests but... for now let's not).
I decided to split out the addition of these tests from other PRs so that it's easier to follow changes to the LSP's function call handling. I'm not particularly concerned with whether the results produced by these tests are "good" or "bad" in this PR, I'm just establishing a baseline.
2 participants
I decided to split out the addition of these tests from other PRs so that it's easier to follow changes to the LSP's function call handling. I'm not particularly concerned with whether the results produced by these tests are "good" or "bad" in this PR, I'm just establishing a baseline.