Fix JSX parsing failures in ternary expressions with nested JSX attributes

[Copilot]

Valid TSX with ternary expressions containing parenthesized identifiers in the true branch and nested JSX with object literals in the false branch produces 30 spurious syntax errors. Standard tsc parses this correctly.

{!isLogin ? (
  DEFAULT_NULL_VALUE
) : (
  <HoverCardText
    label={<div>{nf(1, { precision: 2, rounding: 'down' })}</div>}
  ></HoverCardText>
)}

Root cause

During speculative arrow function parsing, (DEFAULT_NULL_VALUE) : is tried as an arrow signature with return type annotation. The return type parser encounters (<div ... and interprets < as the start of type parameters for a function type. This produces a FunctionType node with a missing parameter list (no ( found).

TypeScript's typeHasArrowFunctionBlockingParseError catches this via isMissingList(parameters) and aborts the speculative parse. The Go port was missing this check, so the speculative parse incorrectly committed, consuming JSX tokens.

Changes

• parser.go — sentinel slice for missing lists: Add a package-level missingListNodes sentinel (make([]*ast.Node, 0, 1)) and isMissingNodeList() helper that compares backing array addresses, porting TS's MissingList / isMissingList concept without modifying the ast package
• parser.go — createMissingList: Add helper method matching TS's createMissingList(), used at all corresponding callsites: parseBracketedList, parseParameters, parseFunctionBlock, parseVariableDeclarationList, parseClassDeclaration, parseEnumDeclaration, parseModuleBlock, parseObjectTypeMembers, and parseParenthesizedArrowFunctionExpression
• parser.go — typeHasArrowFunctionBlockingParseError: Split FunctionType/ConstructorType from ParenthesizedType case and add the missing parameter list check, matching the TS reference:

case ast.KindFunctionType, ast.KindConstructorType:
    return isMissingNodeList(node.FunctionLikeData().Parameters) ||
        typeHasArrowFunctionBlockingParseError(node.Type())
case ast.KindParenthesizedType:
    return typeHasArrowFunctionBlockingParseError(node.Type())

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[bug] JSX parsing fails with spurious syntax errors in ternary expression with nested JSX and multi-property object literals</issue_title>
<issue_description>## Bug Report

tsgo version

7.0.0-dev.20260227.1

Reproduction

This is a fully self-contained reproduction with no external dependencies.

tsconfig.json:

{
  "compilerOptions": {
    "jsx": "preserve",
    "noEmit": true
  }
}

repro.tsx:

import { memo } from 'react'

const HoverCardText = (p: { label: any; text: any; className?: string }) => null
const DEFAULT_NULL_VALUE = '--'
const t = (key: string, params?: Record<string, any>) => key
const nf = (v: any, opts: { precision: number; rounding: string }) => String(v)

export const Example = memo(function Example() {
  const isLogin = true

  return (
    <div>
      <div>{t('label')}</div>
      {!isLogin ? (
        DEFAULT_NULL_VALUE
      ) : (
        <HoverCardText
          className="test"
          label={
            <div>
              {t('some.key', {
                s1: nf(1, { precision: 2, rounding: 'down' }),
                s2: nf(2, { precision: 2, rounding: 'down' }),
              })}
            </div>
          }
          text={
            <div>
              {nf(0, { precision: 2, rounding: 'down' })} USDT
            </div>
          }
        ></HoverCardText>
      )}
    </div>
  )
})

Expected behavior

No syntax errors — the JSX is valid. Standard tsc (5.x) compiles this without any syntax issues (only reports the expected TS2307: Cannot find module 'react' error since React isn't installed).

Actual behavior

tsgo --noEmit reports 30 spurious syntax errors starting at the <HoverCardText JSX element, such as:
repro.tsx(18,11): error TS1005: ',' expected
repro.tsx(19,11): error TS1005: ',' expected
repro.tsx(21,15): error TS1005: '(' expected
repro.tsx(21,18): error TS1003: Identifier expected....
The parser appears to fail to recognize the JSX context and instead interprets JSX attributes as JavaScript object properties.

Key observations from investigation

Removing any one of these elements makes the bug disappear:
The ternary expression (? ... : ...)
The

{t('label')}

preceding the ternary
The second property in the object literal inside label (s2: nf(...))
Reducing the object literal to a single property inside the label JSX attribute makes it work.
Using a string literal ('--') instead of DEFAULT_NULL_VALUE in the ternary's truthy branch also makes it work.
tsc 5.x handles this code correctly in all cases.
The bug appears to involve the parser's JSX state management when processing deeply nested expressions (ternary → JSX → JSX attribute → JSX child → function call → object literal with multiple properties containing nested object literals).</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [bug] JSX parsing fails with spurious syntax errors in ternary expression with nested JSX and multi-property object literals #2936

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[jakebailey]

Not sure we can do anything better. We really do rely on this logic.

[Copilot]

Pull request overview

This PR fixes a JSX parsing bug where valid TSX code containing a ternary expression with a parenthesized identifier in the true branch and nested JSX with multi-property object literals in the false branch produces spurious syntax errors.

Root cause: During speculative arrow function parsing, (DEFAULT_NULL_VALUE) : was being tried as an arrow function signature with return type annotation. The return type parser encountered <div ... and interpreted < as type parameters starting a FunctionType node. TypeScript's typeHasArrowFunctionBlockingParseError catches this via isMissingList(parameters) and aborts the speculative parse. The Go port was missing this check.

Changes:

• Adds a missingListNodes package-level sentinel and isMissingNodeList() helper in parser.go, porting TypeScript's MissingList/isMissingList concept without modifying the ast package
• Changes parseBracketedList, parseParameters, parseFunctionBlock, parseVariableDeclarationList, parseClassDeclaration, parseEnumDeclaration, parseModuleBlock, parseObjectTypeMembers, and parseParenthesizedArrowFunctionExpression to use createMissingList() instead of parseEmptyNodeList() when the opening token is absent
• Adds the isMissingNodeList(Parameters) check in typeHasArrowFunctionBlockingParseError for KindFunctionType/KindConstructorType
• Adds a compiler test with 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/parser/parser.go	Core fix: adds sentinel-based missing list infrastructure and corrects typeHasArrowFunctionBlockingParseError
testdata/tests/cases/compiler/jsxTernaryWithObjectInAttribute.tsx	New compiler test reproducing the reported bug scenario
testdata/baselines/reference/compiler/jsxTernaryWithObjectInAttribute.errors.txt	Baseline showing only expected semantic errors (no spurious parse errors)
testdata/baselines/reference/compiler/jsxTernaryWithObjectInAttribute.symbols	Symbol resolution baseline showing correct parsing
testdata/baselines/reference/compiler/jsxTernaryWithObjectInAttribute.types	Type checking baseline showing correct parsing