Panic: nil pointer in NodeList.HasTrailingComma during incremental rebuild (build-mode declaration printer) — 7.0.2 and current nightly

[nikeedw]

Stack trace

Three worker goroutines panic identically per run; first one below (from typescript@7.1.0-dev.20260726.1; typescript@7.0.2 produces the same frames at the same lines):

panic: runtime error: invalid memory address or nil pointer dereference [recovered, repanicked]
[signal SIGSEGV: segmentation violation code=0x2 addr=0xc pc=0x1045fcf98]

goroutine 39500 [running]:
sync.(*WaitGroup).Go.func1.1()
	sync/waitgroup.go:251 +0x48
panic({0x1055aae20?, 0x1058a0e60?})
	runtime/panic.go:860 +0x12c
github.com/microsoft/typescript-go/internal/ast.(*Node).End(...)
	github.com/microsoft/typescript-go/internal/ast/ast.go:194
github.com/microsoft/typescript-go/internal/ast.(*NodeList).HasTrailingComma(...)
	github.com/microsoft/typescript-go/internal/ast/ast.go:143
github.com/microsoft/typescript-go/internal/printer.(*Printer).hasTrailingComma(0x23bcc53aadc0?, 0x104c19f78?, 0x23bd0871dae8?)
	github.com/microsoft/typescript-go/internal/printer/printer.go:4774 +0x28
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitListRange(0x23bd2c208700, 0x105802028, 0x23bd0741f760, 0x23bd0750cd48, 0xd210, 0x10430f7ec?, 0x20?)
	github.com/microsoft/typescript-go/internal/printer/printer.go:4755 +0x2bc
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitList(0x23bd2c208700, 0x105802028, 0x23bd0741f760, 0x23bd0750cd48, 0xd210)
	github.com/microsoft/typescript-go/internal/printer/printer.go:4700 +0x94
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitTypeParameters(0x1055c6000?, 0x23bd07542c60?, 0x23bd0741f760?)
	github.com/microsoft/typescript-go/internal/printer/printer.go:1506 +0x4c
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitFunctionType(0x23bd2c208700, 0x23bd0741f760)
	github.com/microsoft/typescript-go/internal/printer/printer.go:1928 +0x15c
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitTypeNode(0x23bd2c208700, 0x23bd0741f760, 0x871dcb8?)
	github.com/microsoft/typescript-go/internal/printer/printer.go:2309 +0x20c
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitTypeNodePreservingExtends(...)
	github.com/microsoft/typescript-go/internal/printer/printer.go:2271
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitTypeNodeOutsideExtends(...)
	github.com/microsoft/typescript-go/internal/printer/printer.go:2265
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitTypeAnnotation(0x23bd2c208700, 0x23bd0741f760)
	github.com/microsoft/typescript-go/internal/printer/printer.go:1516 +0x84
github.com/microsoft/typescript-go/internal/printer.(*Printer).emitPropertySignature(0x23bd2c208700, 0x23bd08134428)
	github.com/microsoft/typescript-go/internal/printer/printer.go:1647 +0x78

Further up the same stacks: emitImportTypeNode (several frames) and printer.(*Printer).Write, i.e. build-mode declaration-text printing. Full 3-goroutine dump available on request.

This looks like the same underlying failure as microsoft/typescript-go#3467 (identical bottom frames ast.(*Node).End → NodeList.HasTrailingComma → printer.hasTrailingComma → emitListRange), which was hit through the LSP hover path and is closed — this report is the build-mode / incremental path, and it still reproduces on the current nightly.

Steps to reproduce

Reproduces 100% deterministically (5/5 runs) on our project, but only via the incremental path:

1. tsc --noEmit on a clean tree (writes tsconfig.tsbuildinfo) → exits 0.
2. Apply a small refactor. Five different minimal edits all trigger it; the simplest is renaming a generic setter action on one mobx-state-tree store — updateField<Key extends keyof typeof self>(key, value) → onChangeField (16 changed lines across 3 files; the same method name already exists on a sibling store type, and a view elsewhere returns the union of the two store instance types).
3. tsc --noEmit again → panic above.

Notes:

• Deleting tsconfig.tsbuildinfo between steps 2 and 3 makes the run pass — cold full checks never crash; only the rebuild that reuses build info does.
• --singleThreaded crashes identically, so it is not a concurrency race.
• Version matrix on the identical tree + edit: typescript@7.0.2 crash, typescript@7.1.0-dev.20260726.1 crash (recipe re-run natively with the nightly, including rebuilding the buildinfo with it); @typescript/typescript6@6.0.2 clean, typescript@5.9.2 clean (same 15 pre-existing unrelated TS7006 diagnostics before and after the edit, so the edit is type-correct).
• Besides the rename, four other small edits reproduced the same panic on this codebase over the past days: deleting an unused model property + the views reading it; adding a co-located interface X extends Instance<typeof Model> into a model's own file; swapping a types.compose member from a locally-declared model to an imported one; using a shared type-guard for narrowing inside another model's action.
• Environment: macOS arm64 (Darwin 25.5.0), Node v24.14.0, pnpm. Project: Vite + React app, ~2k modules, mobx-state-tree@7.3.1. Relevant compilerOptions: strict, noEmit: true, incremental: true, moduleResolution: "bundler", verbatimModuleSyntax, isolatedModules, skipLibCheck, target/module: ESNext.

The codebase is private, so I can't attach it. I tried to minimize (two MST roots with the same-named generic keyof typeof self setter, a view returning the union of both instance types, 60-field models, same incremental+rename recipe) — the synthetic project does not crash, so the trigger seems to need the real project's type complexity. Happy to bisect, run instrumented/debug builds, or capture whatever extra diagnostics would help against the real repo.

[RyanCavanaugh]

We definitely need some way to repro this. I put several agents to work on it and none of them could come up with any codepath that gets here. Bisecting to a specific subset of code (which you can then anonymize or whatever) would be the best way forward

[nikeedw]

Root cause found, with a self-contained 2-file repro. I built tsgo from source and instrumented it to catch the producer of the nil rather than the consumer.

Proposed fix in microsoft/typescript-go#4842 — but please read the "What still needs your judgement" section at the bottom before treating it as ready.

Minimal repro (no MST, no private code)

src/a.ts

declare const brand: unique symbol

const state = { name: '', count: 0, [brand]: true }

export const api = {
    setField: <K extends keyof typeof state>(key: K, value: (typeof state)[K]): void => {
        state[key] = value
    },
}

src/b.ts

import { api } from './a'

export const merged = { ...api }

tsconfig.json

{
    "compilerOptions": {
        "strict": true,
        "target": "ESNext",
        "module": "ESNext",
        "moduleResolution": "bundler",
        "noEmit": true,
        "incremental": true,
        "skipLibCheck": true
    },
    "include": ["src"]
}

Steps:

1. tsc → exit 0, writes tsconfig.tsbuildinfo
2. append any line to src/b.ts (e.g. export const touched = 1)
3. tsc → panic
4. rm tsconfig.tsbuildinfo && tsc → exit 0

Crashes on typescript@7.0.2, typescript@7.1.0-dev.20260806.1, and a source build of main @ 86cc476. @typescript/typescript6@6.0.3 is clean.

What is nil

internal/checker/pseudotypenodebuilder.go, the PseudoTypeKindSingleCallSignature branch (lines 184–190 @ 86cc476):

res := make([]*ast.Node, 0, len(d.TypeParameters))
for _, tp := range d.TypeParameters {
    res = append(res, b.reuseNode(tp.AsNode()))   // ← can be nil, not checked
}
typeParams = b.f.NewNodeList(res)

reuseNode returns nil when the recovery boundary in tryReuseExistingNodeHelper fails (nodecopy.go:222-232). The nil goes straight into the type parameter NodeList. The printer later dereferences the list's last element in NodeList.HasTrailingComma (ast.go:141-142) → nil deref. addr=0xc is the offset of Loc.end within ast.Node.

Note that reuseTypeNode (nodecopy.go:56-73) handles exactly this nil — it reports an inference fallback and re-serializes from the checker. This call site is the one that doesn't.

Producer stack, obtained by patching NewNodeList to panic when handed a nil element (abridged):

ast.(*NodeFactory).NewNodeList
checker.(*NodeBuilderImpl).pseudoTypeToNode                      pseudotypenodebuilder.go:189
checker.(*NodeBuilderImpl).pseudoTypeToNodeWithCheckerFallback   pseudotypenodebuilder.go:44
checker.(*NodeBuilderImpl).serializeTypeForDeclaration           nodebuilderimpl.go:2256
checker.(*NodeBuilderImpl).addPropertyToElementList              nodebuilderimpl.go:2605
checker.(*NodeBuilderImpl).createTypeNodesFromResolvedType       nodebuilderimpl.go:2681
checker.(*NodeBuilderImpl).createTypeNodeFromObjectType          nodebuilderimpl.go:2742
...
compiler.(*emitter).emitDeclarationFile

Why this particular shape

Four things have to line up:

1. A generic arrow-function property in an object literal — the pseudochecker classifies it as SingleCallSignature and tries to reuse the original type parameter nodes.
2. The constraint references a binding that cannot be named from the file being emitted.
3. Rewriting the constraint must also fail. This is what I got wrong on my first minimization attempt: normally reuse doesn't fail, it rewrites. Drop the unique symbol from the repro above and you get a perfectly good <K extends "count" | "name">. It only returns nil when the rewrite itself reaches something unnameable.
4. The member has to be structurally inlined into another file's declaration. Single-file versions don't reproduce, because the local is nameable in its own .d.ts.

In the codebase this came from, all four fall out of ordinary mobx-state-tree usage: a generic <Key extends keyof typeof self> setter declared inside .actions(self => ({ ... })), MST's unique symbol brands (147 TS2527s in that project), and types.compose pulling models in across files.

This also resolves the "five unrelated edits crash it" observation from my original report — it is one bug, and each of those edits merely put the same file into the affected set.

Why it only surfaces on the incremental path

For this configuration the declaration printer only ever runs there. internal/execute/incremental/affectedfileshandler.go:99:

if !file.IsDeclarationFile && !useFileVersionAsSignature {
    update.signature = h.computeDtsSignature(file)
}

A cold run goes through updateShapeSignature(file, true) and just uses the file version as the signature — no d.ts is ever printed. A warm run computes the real d.ts shape signature for each affected file, prints it, and hits the nil.

A direct --declaration --emitDeclarationOnly build masks it from the other side: files in this shape always carry declaration errors (TS2527 / TS4023), and their emit is skipped. So the malformed tree is built on every run; only the signature path ever prints it.

Broader than my original report

This is not noEmit-specific:

config	warm run
noEmit + incremental	SIGSEGV
ordinary JS emit + incremental	SIGSEGV
composite: true	SIGSEGV

What I verified

With the patch in microsoft/typescript-go#4842, on main @ 86cc476:

• The repro above passes in all three configurations in that table.
• npx hereby build, lint (0 issues), format (no changes) and test all pass — 57 packages ok, no failures.
• The full baseline corpus, including internal/testrunner against the TypeScript submodule, produces no changed baselines other than the new test's.
• The original private codebase: the warm incremental run that reliably crashed now completes cleanly.

What still needs your judgement

I want to be explicit that this is validated, not proven, and there are decisions in it that are yours rather than mine:

• All of the above ran on one machine — macOS arm64, Go 1.26.5. No other OS or architecture.
• No pre-existing test reaches the new fallback. "Zero changed baselines" is reassuring for regressions, but it cuts both ways: the corpus never exercises this path, so the only evidence that the fallback emits the right thing is the single new baseline plus one private codebase. It is not broad evidence.
• The nil might itself be the bug. My patch treats reuseNode returning nil as legitimate and handles it. But the recovery boundary rewrites typeof state happily when no unique symbol is involved — so it is entirely possible the real defect is that the boundary bails out here, and the fix belongs upstream in tryReuseExistingNodeHelper instead. I could not tell from the outside which of those you consider correct, and if it is the latter, my patch papers over it.
• Calling ReportInferenceFallback is a behavioural choice. I mirrored reuseTypeNode, but under isolatedDeclarations that surfaces a diagnostic. It cannot be a regression, since the path previously produced a nil — but whether reporting is right here, versus abandoning the pseudo fast path for the whole signature the way pseudoTypeToNodeWithCheckerFallback does for Direct, is a design call.
• Projects that used to crash will now write a real d.ts shape signature into .tsbuildinfo. That is the intended outcome, but it does change what lands in build info for them, and it deserves a sanity check that those signatures are stable across runs.
• This fixes one instance, not the class. PseudoTypeKindUnion in the same file does appendTypeNode(b.pseudoTypeToNode(m)), and appendTypeNode dereferences its argument immediately — the same failure mode if a nil ever reaches it. I left it alone rather than guess at a fix for a case I could not reproduce.

Happy to rework the patch in whatever direction you prefer, or to drop it entirely and just leave the diagnosis if you would rather fix it yourselves.

One last note: a debug assert in NewNodeList would have turned this segfault into an actionable panic pointing straight at the producer. That is how I found it.

---

Disclosure, same as on the PR: this investigation was done with the help of Claude Code, driven by me on my own issue. I have verified the diagnosis and the repro myself.

[RyanCavanaugh]

Please never send a PR if you're not willing to sign the CLA -- this is extremely problematic from a legal perspective. I've closed the PR without looking at the code and will archive the PR as soon as it becomes possible to do so (archiving is currently disabled). Once that's done we'll have an agent try to fix this based on the description here.

[nikeedw]

Ryan Cavanaugh (@RyanCavanaugh) Update on the CLA situation, and an apology for the churn.

I have now read the CLA in full and I have no problem signing it — done: @microsoft-github-policy-service agree is posted, and the code is granted in full under the CLA's terms. Since the agreement's §2 covers prior submissions as well, that applies to the closed microsoft/typescript-go#4842 too.

I could not reopen microsoft/typescript-go#4842 myself (no permission after a maintainer close), so the same branch is resubmitted unchanged as microsoft/typescript-go#4846, CLA signed. The earlier refusal was my mistake — you were right that it put the project in an impossible position, and closing without looking was the correct call on your side.

If you would still rather have an agent re-derive the fix from the analysis in this thread and keep both PRs closed, that remains entirely fine with me. The technical caveat from before also stands either way: the patch makes the type-parameter path handle a nil from reuseNode the way reuseTypeNode already does, which removes the crash — but whether the real defect is upstream (why tryReuseExistingNodeHelper fails to finalize the boundary here at all) is a judgement call I leave to you.