Keep JSDoc on expando hosts declared as arrows or function expressions

[Yogesh Kumar (yogesh968)]

Fixes microsoft/TypeScript#63836

Analysis

An expando host can be written either as a function declaration or as a variable
whose initializer is an arrow function / function expression. Declaration emit
turns both into a declare function, but it builds them in two different ways in
transformExpandoHost:

if ast.IsFunctionDeclaration(declaration) {
    // updates the original node
    replacement = append(replacement, tx.Factory().UpdateFunctionDeclaration(declaration.AsFunctionDeclaration(), ...))
} else if ast.IsVariableDeclaration(declaration) && ast.IsFunctionExpressionOrArrowFunction(declaration.Initializer()) {
    // builds a brand new node
    replacement = append(replacement, tx.Factory().NewFunctionDeclaration(...))
}

The first branch goes through Update..., so the result keeps the original node's
position. The second branch synthesizes a node from scratch, so its Loc is
synthesized.

Printer.emitCommentsBeforeNode asks EmitContext.CommentRange(node) for the range
to scan for leading comments, and that getter falls back to node.Loc when no
explicit range was set. For the synthesized node that is a synthesized position, so
emitLeadingCommentsOfNode takes the PositionIsSynthesized path and skips leading
comments entirely — the JSDoc written above the variable statement is silently
dropped from the .d.ts.

Given this input:

/**
 * jsdoc description on `ExpandoArrowNamedExport`
 */
const ExpandoArrowNamedExport = () => { return null; };
ExpandoArrowNamedExport.args = { num: 3 };

export { ExpandoArrowNamedExport };

TypeScript 6.0.3 emits the comment, and tsgo does not:

// tsc 6.0.3                             // tsgo (before)
/**                                      declare function ExpandoArrowNamedExport(): null;
 * jsdoc description on ...              declare namespace ExpandoArrowNamedExport {
 */                                          var args: { num: number; };
export function ExpandoArrowNamedExport(): null;

Fix

Set an explicit comment range on the synthesized function declaration, pointing at
the variable statement — which is where JSDoc on the host is written, and whose
Pos() starts before the leading trivia. This mirrors what the sibling
Update... branch gets for free, and matches the existing idiom a few hundred
lines up in the same file (SetOriginal + SetCommentRange on a synthesized
declaration list).

Alternatives considered: also calling EmitContext.SetOriginal(funcDecl, root).
That copies the original's emit node and makes MostOriginal resolve the
synthesized function back to the variable statement, which is more than is needed
here — the comment range is the only thing the printer is missing — so I kept the
change to the narrower of the two.

Effect on the table in microsoft/TypeScript#63836

Measured against typescript@6.0.3, .js inputs:

	tsc 6.0.3	tsgo before	tsgo after
ExpandoFunctionInlineNamedExport	comment	comment	comment
ExpandoArrowInlineNamedExport	no comment	no comment	comment
ExpandoFunctionNamedExport	comment	comment	comment
ExpandoArrowNamedExport	comment	no comment	comment
ExpandoFunctionDefaultExport	comment	comment	comment
ExpandoArrowDefaultExport	comment	no comment	comment

Two rows converge onto 6.0 behavior. The second row does not: 6.0 drops the comment
when the expando arrow is exported inline, and after this change tsgo keeps it.

The .ts columns of that table are covered too: tsgo routes .ts expando hosts
through this same synthesis, so they gain the comment as well. (6.0 emits those as
declare const X: { (): null; args: ... } instead of a function/namespace pair —
a separate shape difference that this change does not touch.)

I did not try to reproduce that omission. Both branches of transformExpandoHost
describe the same construct, and the only thing separating this row from the
ExpandoArrowNamedExport row directly below it is where the export keyword sits,
which does not seem like a distinction the emitter should be preserving. Suppressing
it again would mean special-casing exported variable statements purely to reproduce
what looks like an artifact of Strada's node reuse. The issue notes this row is
expected to change ("the comment emit fix for arrows will be a breaking change from
TS 6"). Happy to gate it if you would rather hold the line at exact 6.0 parity.

Testing

New test at testdata/tests/cases/compiler/expandoArrowFunctionDeclarationEmitJSDoc.ts
covering the named-export, inline-export and default-export forms, for both arrow
functions and function expressions, with function declarations alongside them as
controls. Baselines were accepted before the fix and re-accepted after, so the diff
on the baseline file shows exactly which comments the change adds.

No other baselines in the suite changed.

Disclosure

Per CONTRIBUTING.md: this patch was authored with AI assistance (Claude Code). I
picked the issue, reviewed the diff and the baseline changes, ran the build, tests,
lint and format locally, and I will be the one responding to review feedback here.

Copilot Checklist

I successfully ran these commands at the end of my session, and they completed without error:

• npx hereby build
• npx hereby test
• npx hereby lint
• npx hereby format

Being straight about the two unticked boxes rather than claiming them — my machine ran
out of disk partway through and I could not get either to complete end to end.

What I did run green, individually:

go test ./internal/testrunner       ok  395.081s   <- all compiler baselines
go test ./internal/execute/...      ok             <- tsc/tsctests/build/watch
go test ./internal/printer/...      ok
go test ./internal/parser/...       ok  193.616s
go test ./internal/checker/...      ok
go test ./internal/transformers/... ok
gofmt -l internal/transformers/declarations/transform.go   (clean)
go vet ./internal/transformers/declarations/               (clean)

The compiler baseline run is the one that matters most for this change, and it wrote
zero files into testdata/baselines/local — every one of the ~49k reference baselines
matched, so nothing outside the new test moved.

npx hereby lint never got as far as linting: building the custom golangci-lint binary
filled the disk (compile: writing output: ... There is not enough space on the disk).
./internal/fourslash/... is the other suite I did not run. Both should be covered by
CI here — please shout if either turns up something and I will fix it.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Jake Bailey (jakebailey)]

We can't really do anything with this unless the CLA is signed

[Copilot]

Pull request overview

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

[Ryan Cavanaugh (RyanCavanaugh)]

Thank you for contributing to the TypeScript native port!

Development has moved from this repository back to the main microsoft/TypeScript repository. GitHub does not have PR transfer functionality, so we're closing this PR here.

If this change is still relevant, please reopen it as a new pull request in microsoft/TypeScript. We'd appreciate your help carrying the contribution over, and we apologize for the extra work.

See microsoft/typescript-go#4918 for more information about the move.