feat: parse parameter decorators for transforms#3001
Open
jtenner wants to merge 6 commits intoAssemblyScript:mainfrom
Open
feat: parse parameter decorators for transforms#3001jtenner wants to merge 6 commits intoAssemblyScript:mainfrom
jtenner wants to merge 6 commits intoAssemblyScript:mainfrom
Conversation
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
changed the title
Contributor
Author
|
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. |
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
1 participant
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.
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
ParameterNodethisparameter decorators onFunctionTypeNodeProgramvalidation pass that rejects surviving parameter decorators once per decorated parameter using the full decorator-list rangeafterInitialize, so transforms can remove the decorators firstWhy
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:
Impact
TS1206if parameter decorators survive to compilationValidation
npm run buildnpm run test:parser -- parameter-decoratorsnpm run test:compiler -- parameter-decorators --noDiffnpm run test:transform