Improve memory usage of formatter

[weswigham]

And throw in a bugfix for the road, plus a (disabled) entrypoint that can make testing formatter changes on the cli easier. Combined, these lower the total count of allocations from around 2 million to 750k per checker.ts format. Byte-wise, it goes from around 113MB allocated to 83MB (36% savings). These, in turn, help performance on cache-limited systems substantially.

[Copilot]

Pull Request Overview

Adds a dedicated fmtMain entrypoint with a benchmark test and refactors the formatter to use value‐typed spans, reuse rule slices, and fix indentation logic—reducing memory allocations substantially.

• Switch *TextRangeWithKind and *tokenInfo to value types and use zero values as sentinels
• Introduce currentRules slice reuse to cut down allocations
• Add fmtMain and applyBulkEdits for standalone formatting plus benchmark in fmt_test.go

Reviewed Changes

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

Show a summary per file

File	Description
internal/format/span.go	Switch to value‐typed spans; reuse currentRules
internal/format/scanner.go	Switch to value‐typed tokenInfo; track last info via bool
internal/format/rulesmap.go	Update getRules to accept and return reusable slice
internal/format/indent.go	Guard against -1 indent and return correct delta
internal/format/context.go	Drop pointer fields in formattingContext
internal/execute/tsc.go	Add fmtMain, applyBulkEdits
internal/execute/fmt_test.go	Add benchmark to profile formatting allocations

Comments suppressed due to low confidence (3)

internal/format/span.go:274

• Comparing value-typed spans against NewTextRangeWithKind(0,0,0) uses a freshly allocated loc and will never equal the zero value sentinel; you need a reliable sentinel (e.g. a boolean flag or check previousRange.Loc == nil).

if w.previousRange != NewTextRangeWithKind(0, 0, 0) && w.formattingScanner.getTokenFullStart() >= w.originalRange.End() {

internal/format/span.go:292

• Unconditionally using tokenInfo.Loc on a zero‐value TextRangeWithKind will panic when Loc is nil; guard with an explicit flag or ensure tokenInfo was actually initialized before accessing its Loc.

if tokenInfo.Loc.Pos() == w.previousRangeTriviaEnd {

internal/execute/tsc.go:26

• strings.Builder is used but "strings" is not imported; add import "strings" to avoid a compile error.

func applyBulkEdits(text string, edits []core.TextChange) string {

[jakebailey]

The actual perf changes seem good, though I think the PR title should be updated to talk just about the perf given the code for the formatting test entrypoint is commented out. (Do we need that code? Can we just keep it locally or just use regular benchmarks?)

[weswigham]

Do we need that code?

I'd like to make it a public entrypoint to the compiler at some point in the future (alongside other LS features), but for now it's useful to keep around as a quick edit for testing and making changes to the formatter without waiting for a full vscode extension reload.

[jakebailey]

Seems fine for now for testing purposes; adding in the formatter as part of the CLI I think will take further discussion. I think a gopls esque model might be the way to go there, so long as we can make the Project system not load any programs in the course of doing non-semantic functionality like formatting.

(That and, configuring it sounds like a nightmare. I'm not sure how much we really want people depending on this anyway.)

[jakebailey]

Ah, I broke this via #979