Skip to content

fix(parser): reject 'const' modifier on type alias type parameter#22828

Closed
Boshen wants to merge 1 commit into
graphite-base/22828from
fix/const-modifier-type-alias
Closed

fix(parser): reject 'const' modifier on type alias type parameter#22828
Boshen wants to merge 1 commit into
graphite-base/22828from
fix/const-modifier-type-alias

Conversation

@Boshen

@Boshen Boshen commented May 29, 2026

Copy link
Copy Markdown
Member

Stacked on #22827.

A const modifier on a type parameter is only valid when the type parameter belongs to a function, method, or class (TS1277) — it is not allowed on a type alias.

Verified against typescript-go (internal/checker/grammarchecks.go): for a const type-parameter modifier the parent must be one of function-like / class-like / function-type / constructor-type / call|construct|method signature, otherwise TS reports "'const' modifier can only appear on a type parameter of a function, method or class".

type T<const U> = U;        // ✗ now errors
type T<U, const V> = V;     // ✗ now errors

interface I<const T> {}     // ✓ still parses
function f<const T>() {}    // ✓ valid
class C<const T> {}         // ✓ valid

The check is scoped to type aliases at the parser level: this matches babel's fixtures and avoids regressing the const-type-parameters positive fixture (which parses interface I<const T>). TypeScript also rejects the interface case, but only as a checker-level diagnostic, so leaving it to a later pass keeps the parser consistent with babel.

Conformance

No regressions across any parser suite (positive/AST stay 100%):

suite negative-pass
parser_babel 1695 → 1696
parser_typescript 1584 → 1585

Flips types/const-type-parameters-invalid (babel) and typeParameterConstModifiers.ts (TypeScript).

🤖 Generated with Claude Code

@github-actions github-actions Bot added the A-parser Area - Parser label May 29, 2026
@Boshen Boshen force-pushed the fix/const-modifier-type-alias branch from a1dcf5e to 3ed3157 Compare May 29, 2026 10:15
@Boshen Boshen force-pushed the fix/ts-decl-single-statement branch from 96b2851 to efa7b94 Compare May 29, 2026 10:15

Boshen commented May 29, 2026

Copy link
Copy Markdown
Member Author

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • 0-merge - adds this PR to the back of the merge queue
  • hotfix - for urgent changes, fast-track this PR to the front of the merge queue

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@graphite-app graphite-app Bot changed the base branch from fix/ts-decl-single-statement to graphite-base/22828 May 29, 2026 10:15
@codspeed-hq

codspeed-hq Bot commented May 29, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 57 untouched benchmarks


Comparing fix/const-modifier-type-alias (3ed3157) with main (9d3d4f7)1

Open in CodSpeed

Footnotes

  1. No successful run was found on graphite-base/22828 (efa7b94) during the generation of this report, so main (9d3d4f7) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

@Boshen Boshen added the 0-merge Merge with Graphite Merge Queue label May 29, 2026

Boshen commented May 29, 2026

Copy link
Copy Markdown
Member Author

Merge activity

  • May 29, 10:22 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.

@camc314

camc314 commented May 29, 2026

Copy link
Copy Markdown
Contributor

The check is scoped to type aliases at the parser level: this matches babel's fixtures and avoids regressing the const-type-parameters positive fixture (which parses interface I). TypeScript also rejects the interface case, but only as a checker-level diagnostic, so leaving it to a later pass keeps the parser consistent with babel.

This feels strange. This is a checker only check in TypeScript, for both interfaces and type decalarations.

It feels like we should just emit an error for both and accept the regression in babel? Babel's fixtures don't completly aligh with TS.

@Boshen Boshen marked this pull request as draft May 29, 2026 11:23
@Boshen Boshen deleted the branch graphite-base/22828 May 31, 2026 09:07
@Boshen Boshen closed this May 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

0-merge Merge with Graphite Merge Queue A-parser Area - Parser

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants