Skip to content

Fix spurious JSDoc modifier errors on object literal members#4448

Open
Copilot wants to merge 22 commits into
mainfrom
copilot/investigate-issue-4437
Open

Fix spurious JSDoc modifier errors on object literal members#4448
Copilot wants to merge 22 commits into
mainfrom
copilot/investigate-issue-4437

Conversation

Copilot AI commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Analysis

In JS files, JSDoc modifier tags like @override, @private, @readonly are reparsed into synthetic modifier nodes on the members they annotate. That's correct for class-like members, but object literal methods and accessors aren't class members, so reparsing modifiers onto them produced spurious grammar errors (TS1042 "modifier cannot be used here" and TS1184 "Modifiers cannot appear here"). Because reparsing happens at parse time, the errors showed up even without checkJs.

Fix

In reparseHosted, skip reparsing JSDoc modifier tags onto method/get/set members when they're being parsed as object literal members (PCObjectLiteralMembers). Class members are unaffected: they still get their modifiers and the usual semantic checks, e.g. @override without a base class still errors.

Tests are consolidated into two cases that vary by @checkJs: true,false to cover both modes from one source file.

Copilot AI and others added 22 commits June 24, 2026 22:50
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Revert the grammar-check churn and the standalone plain JS helper, and
instead skip materializing JSDoc modifiers on object literal
methods/accessors at reparse time, matching the existing @overload
handling. This mirrors tsc, which reports nothing for these in plain JS
or checkJs, while class JSDoc modifiers (e.g. @OverRide) keep their
checkJs semantic validation (TS4121). Add varied tests covering object
literal methods/accessors in plain JS and checkJs, plus a class case
that still errors under checkJs.

Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
Merge the two object-literal JSDoc modifier tests into a single
jsdocModifiersInObjectLiteral test that varies by `@checkJs: true,false`,
and simplify the class test likewise. This removes the near-duplicate
plain/check JS cases and shows both modes from one source file.

Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
@jakebailey jakebailey changed the title Investigating issue 4437 in TypeScript-Go Fix JSDoc modifier errors in unchecked JS files Jun 25, 2026
@jakebailey

Copy link
Copy Markdown
Member

@copilot Fix the PR description and title to now match the state of this change.

Copilot AI changed the title Fix JSDoc modifier errors in unchecked JS files Fix spurious JSDoc modifier errors on object literal members Jun 25, 2026
Copilot AI requested a review from jakebailey June 25, 2026 22:33

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a parser-level bug in the TypeScript-Go JSDoc reparser where JSDoc modifier tags (e.g. @override, @readonly) were being converted into synthetic modifiers on object literal methods/accessors, producing spurious grammar diagnostics even when checkJs is off. The change scopes JSDoc-modifier-to-synthetic-modifier reparsing to class-like members, and adds regression coverage.

Changes:

  • Update reparseHosted to skip reparsing JSDoc modifier tags onto method/get/set nodes when parsing within PCObjectLiteralMembers.
  • Add a compiler regression test covering object literal methods/accessors under @checkJs: true,false.
  • Add a companion compiler test ensuring class members still receive JSDoc modifier semantic validation under checkJs.

Reviewed changes

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

Show a summary per file
File Description
internal/parser/reparser.go Skips converting JSDoc modifier tags into synthetic modifiers for object literal method/get/set members (prevents spurious grammar errors).
testdata/tests/cases/compiler/jsdocModifiersInObjectLiteral.ts New regression test ensuring object-literal members with JSDoc modifier tags do not produce grammar errors (both checkJs modes).
testdata/tests/cases/compiler/jsdocModifiersInClass.ts New regression test ensuring class members still get semantic validation for JSDoc modifiers under checkJs.
`testdata/baselines/reference/compiler/jsdocModifiersInObjectLiteral(checkjs=true false).*`
`testdata/baselines/reference/compiler/jsdocModifiersInClass(checkjs=true false).*`

@jakebailey jakebailey marked this pull request as ready for review June 25, 2026 23:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants