Create declaration emit diagnostic selectors on demand

[Gavin Kline (gwkline)]

Fixes #64720

Analysis

Every declaration the declaration transformer visits installs a diagnostic context. On main this costs two allocations per context:

1. createGetSymbolAccessibilityDiagnosticForNode(input) allocates a selector closure. The selector picks the error message if a symbol used by the declaration turns out to be inaccessible.
2. setupDiagnosticContext returns a second closure that restores the previous context.

The selector is only called from handleSymbolAccessibilityError, that is, when an accessibility error is actually reported, which almost never happens.

This runs for every emitted declaration file. Under noEmit with declaration enabled, it also runs for every file's declaration diagnostics.

Fix

• SymbolTrackerSharedState holds a symbolAccessibilityDiagnosticContext{node, fn} instead of a function. The common path stores the declaration node, and get creates the selector only when an error is reported. Sites that need a custom selector still store a function:
  • default export assignments, including the CommonJS _default/_exported paths
  • class extends expressions
  • dynamic names (checkName)
  • the initial throwDiagnostic sentinel
• setupDiagnosticContext returns the saved state as a struct, and restoreDiagnosticContext reinstates it. Setting up and restoring a context therefore no longer allocates.

createGetSymbolAccessibilityDiagnosticForNode only inspects the node's kind (and, for parameters, its parent) when called. canProduceDiagnostics accepts exactly the kinds it handles. So creating the selector later, from the same node, gives the same result.

Testing

New test declarationEmitInaccessibleNameContexts gives an inferred type that can't be named to:

• variables and destructuring
• function return types and parameters
• class properties and static properties
• constructor parameter properties
• methods and static methods
• getters and accessor pairs
• namespace members
• object literals
• class extends expressions
• expando properties on a function declaration and an arrow function
• default exports

It reports 23 errors across 15 diagnostic codes. Its baselines were generated with the code on main and are unchanged by this PR. No existing baseline changes.

Results

M3 Pro, --extendedDiagnostics:

Program	Allocations	Check time
generator from the issue (1,557 files, noEmit + declaration)	14.5M → 8.7M (−40%)	0.300 s → 0.276 s
private monorepo package, --noEmit (8.6k files)	46.1M → 41.1M (−10.9%)	4.19 s → 4.09 s
same package, declaration build	35.4M → 32.5M (−8.0%)	emitted output identical

The profiling, the patch and this description were produced with Claude Code (Claude Fable 5.1 and Claude Opus 5.5). I have read and understand the change and will handle review myself.

Copilot Checklist

I successfully ran the applicable command at the end of my session, and it completed without error:

• npx hereby validate
• npx hereby validate --api (for TypeScript API changes; no API changes here)

🤖 Generated with Claude Code