Preserve comments when downleveling arrow expression bodies

[Copilot]

Downlevel optional chaining can hoist temporaries from an arrow expression body, forcing the body to become a block with a synthesized return. When the expression had a leading comment, that comment emitted after return, triggering ASI and skipping the expression.

• Emit fix

  • Propagate the original expression range to the synthesized return statement.
  • This keeps leading comments attached before return instead of between return and the returned expression.

• Regression coverage

  • Added an ES2018 compiler test covering an arrow expression body with a leading comment and optional chaining.

const wat = () =>
    // explanatory comment
    thing?.nested?.condition ? "pass" : "fail";

Now emits with the comment before return, avoiding return\n... ASI behavior.

• Fixes Nested nullish coalescing + comment + ES2018 causes function body to be ignored #4722

[Copilot]

Pull request overview

Preserves leading comments when arrow expression bodies are downleveled into blocks, preventing ASI from skipping returned expressions.

Changes:

• Copies the expression source range to synthesized return statements.
• Adds compiler regression coverage and baselines.

Reviewed changes

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

Show a summary per file

File	Description
internal/printer/emitcontext.go	Preserves the expression range on synthesized returns.
testdata/tests/cases/compiler/optionalChainingArrowFunctionCommentEs2018.ts	Adds the regression case.
testdata/baselines/reference/compiler/optionalChainingArrowFunctionCommentEs2018.js	Verifies correct comment placement in emitted JavaScript.
testdata/baselines/reference/compiler/optionalChainingArrowFunctionCommentEs2018.types	Records type output.
testdata/baselines/reference/compiler/optionalChainingArrowFunctionCommentEs2018.symbols	Records symbol output.

[Wesley Wigham (weswigham)]

This clones the expression's pos to the return statement - which is fine IF you also suppress comments on updated. As it is now, there may be duplicated comments in some situations (inline comments, likely).

[Jake Bailey (jakebailey)]

Copilot think harder, ground yourself in Strada's code, etc etc

[Copilot]

Addressed in 38e7d06. I now suppress comments on the rewritten expression when synthesizing the return in VisitFunctionBody, so we keep the ASI-safe return positioning without re-emitting comments from updated.

[Jake Bailey (jakebailey)]

Copilot did you actually have a test for this that showed the difference?

definitely consider redoing the stack such that the first commit is all tests, the second commit is all fixes indicating that things changed

[Jake Bailey (jakebailey)]

Copilot

also consider this test case from #4722 (comment)

// m.ts
declare const o: { a?: number[] };

export const f = () =>
  // comment
  o.a?.length;

[Jake Bailey (jakebailey)]

Copilot this is some interesting code; what did Strada do?

[Copilot]

Strada's convertToFunctionBlock simply applies the expression's text range to both the synthesized return and block (factory/nodeConverters.ts:54-60). It has no scanner check or comment suppression. That currently duplicates same-line comments, while suppressing return comments unconditionally loses preceding-line comments in tsgo; this conditional preserves the preceding-line case while avoiding the inline duplicate.

[Jake Bailey (jakebailey)]

Copilot Is there precedence for this in the repo? Existing helpers? Existing cases in the old compiler, even?

[Copilot]

Pull request overview

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