Add baseline tests from signature help #1485
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR ports Strada's baselining signature help tests to the LSP implementation. The change introduces comprehensive baseline tests for signature help functionality across various TypeScript and JavaScript scenarios, revealing differences between the old system and LSP signature help behavior. There is one new test failure showing a nil response issue.
Key Changes
- Ported comprehensive signature help baseline tests from Strada
- Added 30+ new baseline test files covering various signature help scenarios
- Tests cover JSDoc tags, overloads, generics, rest parameters, constructors, and more
| } else { | ||
| t.Fatal("Unsupported param label kind.") | ||
| } | ||
| signatureLine = strings.Replace(signatureLine, activeParamLabel, "**"+activeParamLabel+"**", 1) |
There was a problem hiding this comment.
This should really only be done if we don't come back with the tuple representation.
| if activeParam.Label.String != nil { | ||
| activeParamLabel = *activeParam.Label.String | ||
| } else if activeParam.Label.Tuple != nil { | ||
| activeParamLabel = signatureLine[(*activeParam.Label.Tuple)[0]:(*activeParam.Label.Tuple)[1]] |
There was a problem hiding this comment.
This is slightly wrong because these are supposed to be UTF-16 offsets. But it's not really "testable' today because we don't even come back with this data.
There was a problem hiding this comment.
You could utf16.Encode + slice + utf16.Decode
|
The stuff I need to do to get signature offsets is absolutely gross, so I would like to get a review once I fix the conflicts. |
This change ports over Strada's baselining signature help tests. There is only one new test failure which has the following problem:
Beyond that, signature help in LSP is surprisingly different in a few ways, and so reconstructing similar visualization is going to be weird. Stuff worth calling out:
There is no section for tags. Everything just appears in docs. (expected)
We currently don't return any docs! We should do that eventually.
There is no notion of an "applicable span" so that the editor can avoid retriggers. Our testing infrastructure used to leverage this.
Editors like VS Code bold out the signature help parameter based on the label of the parameter itself. There is a "tuple" version that theoretically avoids a string search, but we don't use the "tuple" version of parameter labels for signature help. This is sketchy for reasons...
I am currently testing things in a very lazy way where these are indistinguishable. I probably should do it a bit differently.