Fix spurious JSDoc modifier errors on object literal members#4448
Open
Copilot wants to merge 22 commits into
Open
Fix spurious JSDoc modifier errors on object literal members#4448Copilot wants to merge 22 commits into
Copilot wants to merge 22 commits into
Conversation
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>
Copilot created this pull request from a session on behalf of
jakebailey
June 25, 2026 22:24
View session
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
Contributor
There was a problem hiding this comment.
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
reparseHostedto skip reparsing JSDoc modifier tags ontomethod/get/setnodes when parsing withinPCObjectLiteralMembers. - 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).*` |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Analysis
In JS files, JSDoc modifier tags like
@override,@private,@readonlyare 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 withoutcheckJs.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.@overridewithout a base class still errors.Tests are consolidated into two cases that vary by
@checkJs: true,falseto cover both modes from one source file.