Skip to content

feat: parse parameter decorators for transforms#3001

Open
jtenner wants to merge 6 commits intoAssemblyScript:mainfrom
jtenner:parse-parameter-decorators
Open

feat: parse parameter decorators for transforms#3001
jtenner wants to merge 6 commits intoAssemblyScript:mainfrom
jtenner:parse-parameter-decorators

Conversation

@jtenner
Copy link
Contributor

@jtenner jtenner commented Mar 27, 2026

Summary

This PR makes parameter decorators parseable and preservable in the AST so transforms can inspect or remove them before compilation-time validation runs.

This is intentionally not a new end-user language feature. Any parameter decorators that survive transform time still produce TS1206: Decorators are not valid here.

What Changed

  • added AST storage for parameter decorators on ParameterNode
  • added AST storage for explicit-this parameter decorators on FunctionTypeNode
  • taught the shared parameter parser to preserve decorators across function declarations, methods, constructors, function types, function expressions, and parenthesized arrow functions
  • updated the AST serializer to round-trip preserved parameter decorators
  • added a Program validation pass that rejects surviving parameter decorators once per decorated parameter using the full decorator-list range
  • ran that validation after afterInitialize, so transforms can remove the decorators first
  • added parser, compiler, and transform coverage for accepted syntax, delayed rejection, and transform-time removal
  • documented the transform hook timing in the transform-facing API comments and example transforms

Why

The parser and transform pipeline can use preserved parameter decorators as an AST-level extension point without committing AssemblyScript to supporting them as regular language syntax.

That gives transform authors a useful hook while keeping the language semantics unchanged:

  • transforms can read or erase parameter decorators
  • the compiler still rejects them if they remain after transform time
  • public-facing docs do not need to advertise parameter decorators as supported syntax

Impact

  • transform authors can now observe and rewrite parameter decorators before validation
  • end users still get TS1206 if parameter decorators survive to compilation
  • constructor parameter properties continue to receive no special decorator semantics

Validation

  • npm run build
  • npm run test:parser -- parameter-decorators
  • npm run test:compiler -- parameter-decorators --noDiff
  • npm run test:transform

jtenner added 5 commits March 26, 2026 23:49
Extend parameter AST nodes to retain decorators, including explicit-this decorators on function signatures, without forcing a broad constructor API churn.

Teach both parameter parsers to accept stacked decorators on regular, rest, explicit-this, constructor-property, function-type, and parenthesized-arrow parameters.

Update the AST builder to serialize parameter decorators inline so parser fixtures can round-trip the new syntax faithfully.

Add a focused parser fixture covering the preserved syntax surface before deferred validation is introduced.
Add a Program-owned validation pass that walks the final AST and reports TS1206 once per decorated parameter, using the full decorator-list span for the diagnostic range.

Invoke that validation from compile after transforms have had their afterInitialize window, so transformers can still remove parameter decorators before any diagnostics are emitted.

Add a dedicated compiler rejection fixture covering regular, rest, explicit-this, constructor-property, function-type, function-expression, and arrow-parameter cases.
Add a dedicated transform input containing the same invalid parameter-decorator forms exercised by the compiler rejection fixture.

Introduce ESM and CommonJS afterInitialize transforms that walk the AST and strip parameter decorators, including explicit-this decorators on function signatures.

Extend the transform test scripts to compile that input with the stripping transforms, proving no TS1206 diagnostics are emitted once transforms remove the decorators in time.
@jtenner jtenner changed the title [codex] Parse parameter decorators for transforms feat: parse parameter decorators for transforms Mar 27, 2026
@jtenner jtenner marked this pull request as ready for review March 27, 2026 04:35
@jtenner
Copy link
Contributor Author

jtenner commented Mar 27, 2026

Whoops! I forgot to check the validation scripts locally. Everything looks good now.

I hope this contribution finds it's way to main because I want to use it to make some very cheeky transforms for my webgpu implementation.

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.

1 participant