String in string completions + plain switch completion

[gabritto]

In this PR:

• String completions, excluding string completions in module positions, e.g. in triple slash reference path strings, because those need some module resolution and package functions that we haven't ported yet. Also missing for now is the case for string completions in call arguments, because that needs signature help, so it'll come in a follow-up once signature help is merged.
• Plain case clause completions, both for string and non-string completions.
• insertTextFormat is now nil for plain text completions, because that's the default.

[Copilot]

Pull Request Overview

This PR standardizes the use of QuoteChar across the codebase, updates string literal escaping and completions logic, and removes redundant explicit plain text formatting in completion items.

• Renames internal type and variable “quoteChar” to “QuoteChar” across tests and utilities.
• Adjusts completions tests and related logic to rely on default plain text formatting rather than explicitly setting InsertTextFormat.
• Introduces new test cases for string literal and switch completions while refining completion item range calculations.

Reviewed Changes

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

Show a summary per file

File	Description
internal/printer/utilities_test.go	Renamed quoteChar to QuoteChar in tests for consistency.
internal/printer/utilities.go	Updated type and parameter names for quote related functions.
internal/ls/utilities.go	Made isInString exported as IsInString and added helper funcs.
internal/ls/completions_test.go	Removed explicit InsertTextFormat for plain text completions.
internal/ls/completions.go	Adjusted completion item range handling and parameter types.
internal/checker/* and internal/ast/*	Minor updates and additions supporting the above changes.

Comments suppressed due to low confidence (3)

internal/ls/completions_test.go:46

• Verify that the removal of explicit 'InsertTextFormat' for plain text completions does not negatively affect clients that expect this formatting. It would be helpful to ensure adequate test coverage for completions with default plain text formatting.

insertTextFormatPlainText := ptrTo(lsproto.InsertTextFormatPlainText)

internal/ls/completions.go:4031

• Ensure that constructing the insert range using l.createLspPosition produces the correct boundaries relative to the previous implementation. Adding or updating tests for edge cases around range calculations may prevent any regressions.

insertRange := &lsproto.Range{ Start: optionalReplacementSpan.Start, End:   l.createLspPosition(position, file), }

internal/ls/utilities.go:18

• Confirm that the new exported IsInString function maintains the same logic as the original isInString to avoid unexpected differences in behavior.

func IsInString(sourceFile *ast.SourceFile, position int, previousToken *ast.Node) bool {

[jakebailey]

There's a lot of uncovered code (based on the codecov extension), are you just waiting for fourslash to have more tests?

I skimmed it and it seems fine but, checking if there are quick things we could throw in to get more coverage.

[gabritto]

There's a lot of uncovered code (based on the codecov extension), are you just waiting for fourslash to have more tests?

I skimmed it and it seems fine but, checking if there are quick things we could throw in to get more coverage.

Yes, basically. It's a bit time consuming to figure out what tests to port (e.g. what tests cover what, what tests don't depend on yet unported code, etc), write them as unit tests, etc, and the idea is we'll have fourslash tests sometime soon, so I didn't want to duplicate that work. But I could be convinced to go and add a few more tests. Do you think it's worth it?

[jakebailey]

I think if it's easy, it might be; I just notice stuff like:

Where it seems like one or two tests might add a good bit of coverage.