…sion (#23147)

`oxc_parser` emitted TS1477 ("An instantiation expression cannot be followed by a property access") for parenthesized instantiation expressions such as `(a<b>).c` when `preserve_parens: false` (the mode oxfmt and oxlint use). tsc and Babel accept it — only the *unparenthesized* form is an error.

The old check keyed off `lhs` being a `TSInstantiationExpression`, but the `ParenthesizedExpression` wrapper that distinguishes `(a<b>).c` from `a<b>.c` is dropped when `preserve_parens` is off, so the bare instantiation leaked through.

## Fix

Emit TS1477 only when the instantiation expression is *not* parenthesized. Instead of relying on a `ParenthesizedExpression` node surviving the AST, detect it by span: an instantiation built in the member-expression loop starts at `lhs_span`, while one unwrapped from a stripped paren starts past the `(`. A shared helper covers both the property-access (`.`) and element-access (`[`) branches.

| source | result | notes |
| --- | --- | --- |
| `a<b>.c` | TS1477 | |
| `a<b>?.[c]` | TS1477 | element access on a bare instantiation |
| `a?.b<c>.d` | TS1477 | |
| `(a<b>).c` | ok | the fix |
| `(a<b>)[c]` / `(a<b>)?.[c]` | ok | the fix |
| `(a).b<c>.d` | TS1477 | parens wrap `a`, not the instantiation |

Correct regardless of `preserve_parens`; under the default (`true`) behavior is unchanged, so no conformance snapshots move.

Note: tsc only checks property access (`parsePropertyAccessExpressionRest`), so it does not flag `a<b>?.[c]` — an apparent oversight, since accessing a member of an instantiation expression is the same operation either way. Babel flags both, and this PR keeps oxc's existing behavior for the unparenthesized element-access case.

Closes #23133.

Alternative to #23135 (same issue, same resulting behavior). That PR records parenthesized instantiation expressions in a new `ParserState` set; this one derives the same fact from spans, needing no extra parser state.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

…sion (#23147)

`oxc_parser` emitted TS1477 ("An instantiation expression cannot be followed by a property access") for parenthesized instantiation expressions such as `(a<b>).c` when `preserve_parens: false` (the mode oxfmt and oxlint use). tsc and Babel accept it — only the *unparenthesized* form is an error.

The old check keyed off `lhs` being a `TSInstantiationExpression`, but the `ParenthesizedExpression` wrapper that distinguishes `(a<b>).c` from `a<b>.c` is dropped when `preserve_parens` is off, so the bare instantiation leaked through.

## Fix

Emit TS1477 only when the instantiation expression is *not* parenthesized. Instead of relying on a `ParenthesizedExpression` node surviving the AST, detect it by span: an instantiation built in the member-expression loop starts at `lhs_span`, while one unwrapped from a stripped paren starts past the `(`. A shared helper covers both the property-access (`.`) and element-access (`[`) branches.

| source | result | notes |
| --- | --- | --- |
| `a<b>.c` | TS1477 | |
| `a<b>?.[c]` | TS1477 | element access on a bare instantiation |
| `a?.b<c>.d` | TS1477 | |
| `(a<b>).c` | ok | the fix |
| `(a<b>)[c]` / `(a<b>)?.[c]` | ok | the fix |
| `(a).b<c>.d` | TS1477 | parens wrap `a`, not the instantiation |

Correct regardless of `preserve_parens`; under the default (`true`) behavior is unchanged, so no conformance snapshots move.

Note: tsc only checks property access (`parsePropertyAccessExpressionRest`), so it does not flag `a<b>?.[c]` — an apparent oversight, since accessing a member of an instantiation expression is the same operation either way. Babel flags both, and this PR keeps oxc's existing behavior for the unparenthesized element-access case.

Closes #23133.

Alternative to #23135 (same issue, same resulting behavior). That PR records parenthesized instantiation expressions in a new `ParserState` set; this one derives the same fact from spans, needing no extra parser state.

🤖 Generated with [Claude Code](https://claude.com/claude-code)