[collin-thomas]

For the 1.0.0 release. Fixes the language-server timing test that failed four times in recent CI runs, plus a real offset bug found along the way. Independent of #151.

The flaky test

lsp/src/typescript-service.linear-time.test.ts checks that finding <script> blocks stays linear on half-typed markup. It times an input and one four times its size: linear work grows about 4×, quadratic about 16×, and the bar is 8.

All four CI failures were the same case, "a quote that never ends" (<script type="aaa… at 4 MB and 16 MB). Those runs read 12.2, 12.6, 16.5 and 16.6. It reads about 4 locally.

Two things were wrong.

1. The scanner copied the page on every scan. scanScripts lowercased the whole page to match tag names in any case. For this input that copy was most of the time measured, about 165 of 195 ns per KB, so the test was mostly timing a 16 MB allocation per run. The language server also runs this scan on keystrokes.

2. The check timed reading memory against a fixed bar. With the copy gone, this case is one native search over the text. Its cost per character depends on whether the text fits the runner's CPU caches. On one CI runner a plain native search read 5.2 to 5.6 at 1 MB vs 4 MB, where linear should read 4. Cache sizes differ between runners, and an earlier fix that raised the sizes from 256 KB to 4 MB only moved the edge.

I couldn't reproduce the 12–16 readings on the runners I sampled; the old code read linear there too. So I can't say how much of each failure was the copy and how much was the cache. The test change below holds either way.

Changes

• typescript-blocks.ts: tag names are compared in place, in ASCII case, as an HTML parser compares them. No copy of the page is made.
• typescript-service.linear-time.test.ts: the memory-bound case is now measured against a native search over the same two texts. Both pay the same cost of reading memory on any runner, so that cost cancels out. Linear work reads about 1, and the bar is 2. The other cases run JavaScript loops, have not flaked, and keep their bar of 8.

Readings of the new check, at the test's sizes (4 MB vs 16 MB):

	Local (M1)	CI runner
New scan	0.98–1.06	0.98–1.02
Deliberately quadratic control	3.27–3.45	3.29–3.39

The real bug found along the way

Unicode lowercasing can make a string longer: "İ".toLowerCase() is two characters. Positions found in the lowercased copy were used on the original page, so after every İ they pointed one character further on. A TypeScript block after "İstanbul" came back with a stray </ on its end, which then showed up in diagnostics and editor features. A new test fails without the fix. #151 fixes the same pattern in five other places.

Verification

• Language-server unit tests (2,700) and linear-time tests: pass locally.
• Language-server typecheck, format, spelling: clean.
• The temporary probe that collected the CI readings was removed in the last commit.

🤖 Generated with Claude Code