Signature help implementation

[navya9singh]

This pr covers mostly everything that is needed for signature help except for signature help in .js files. Some tests that I haven't yet ported from Strada are tests for:

1. Tagged templates
2. Verify no signature help
3. Filtered triggers
4. Tests with JSDoc comments and other comments. It needs some changes in the test setup

[Copilot]

Pull Request Overview

This PR implements support for signature help in the language server and makes extensive naming refactors throughout the checker and utility modules. Key changes include adding a new handler for signature help in the server, updating configuration for the SignatureHelpProvider, and renaming many internal API functions (e.g. getSignaturesOfType → GetSignaturesOfType) to improve consistency and clarity.

Reviewed Changes

Copilot reviewed 16 out of 16 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
internal/lsp/server.go	Adds new case handling for SignatureHelpParams and configures the signature help provider.
internal/ls/utilities.go	Updates comments and refactors type argument info functions without altering behavior.
internal/checker/utilities.go	Renames internal helper functions (e.g. CanHaveSymbol, IsCallOrNewExpression) for consistency.
internal/checker/types.go	Adds accessor methods on Signature and TupleType for better API exposure.
internal/checker/services.go	Consistently replaces lower-case API functions with their exported versions.
internal/checker/relater.go	Refactors signature comparison and tuple handling to use new exported functions.
internal/checker/printer.go	Adjusts printer logic to use the new exported APIs and updates variadic parameter expansion.
internal/checker/jsx.go	Updates JSX-related checks to use renamed functions.
internal/checker/inference.go	Updates inference utilities with new function names.
internal/checker/flow.go	Refactors flow analysis to call updated API names.
internal/checker/checker.go	Widespread updates to use capitalized exported API functions for type retrievals and checks.
internal/astnav/tokens.go	Adds a new helper function, HasQuestionToken, for token analysis.
internal/ast/utilities.go	Adds helpers for handling template literal tokens and string text nodes.
_submodules/TypeScript	Updates the submodule commit to a new revision.

[andrewbranch]

This is looking pretty good overall. Beyond the comments I left, I suggest you look at every declaration of a slice and ask these questions:

• is this a displayParts slice that should just be a string or a strings.Builder?
• if not, can I allocate it with the correct capacity up front?

[andrewbranch]

This can be a single initialization

[andrewbranch]

I would use a strings.Builder here

[andrewbranch]

This is the only call to getSignatureHelpItem, and callTargetDisplayParts is always length 0 or 1. It could just be a string. We know we're not going to have display parts anymore, so it doesn't seem like there's a need to keep the slices around. A lot of things can probably just become strings.

[andrewbranch]

This can be allocated with the correct length/capacity

[jakebailey]

I think this technically works due to the evaluation order of multi-returns, but it kinda hurts my head. I'd personally rather this callback return a struct with the two results (which are then unpacked or returned as-is), or this call be split out into its own line before the return.

[jakebailey]

e.g.

func GetResolvedSignatureForSignatureHelp(node *ast.Node, argumentCount int, c *Checker) (*Signature, []*Signature) {
	type result struct {
		signature *signature
		candidates []*signature
	}
	result := runWithoutResolvedSignatureCaching(c, node, func() result {
		signature, candidates := c.getResolvedSignatureWorker(node, CheckModeIsForSignatureHelp, argumentCount)
		return result{signature, candidates}
	})
	return result.signature, result.candidates
}

outdated