refactor(ast): reorder fields to reflect their visit order. #3994
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
CodSpeed Performance ReportMerging #3994 will not alter performanceComparing Summary
|
Merge activity
|
Boshen
force-pushed
the
07-01-refactor_ast_reorder_fields_to_reflect_their_visit_order
branch
from
e4f27b3
to
0fe22a8
Compare
graphite-app
bot
deleted the
07-01-refactor_ast_reorder_fields_to_reflect_their_visit_order
branch
|
@rzvxa I'm late on this one, but a question: Does this new order align with |
It is both, That's the order they would get interpreted; And we already visit them in this interpretation order, Right now we have the exact same visit order as our field definitions, If we find a conflict with the interpretation order we probably should consider it as a bug(unless we have a good reason for keeping it out of order) |
## [0.16.3] - 2024-07-02 ### Features - b257d53 linter: Support report `@typescript-eslint/consistent-type-imports` (#3895) (mysteryven) ### Bug Fixes - 23038ad codegen: Print `TSFunctionType` inside `TSTypeAssertion` (#3999) (Boshen) - d995f94 semantic: Resolve reference incorrectly when a parameter references a parameter that hasn't been defined yet (#4004) (Dunqing) - bdee156 transformer/typescript: `declare class` incorrectly preserved as runtime class (#3997) (Dunqing) - a50ce3d transformer/typescript: Missing initializer for class constructor arguments with `private` and `protected` modifier (#3996) (Dunqing) ### Refactor - 0fe22a8 ast: Reorder fields to reflect their visit order. (#3994) (rzvxa) - d0eac46 parser: Use function instead of trait to parse normal lists (#4003) (Boshen) Co-authored-by: Boshen <Boshen@users.noreply.github.com>
Won't fix #4142 It is similar to #3994 but for those types that weren't relying on this order. It seems to be the right order. technically speaking it is a breaking change but I know as a fact that it won't have a big difference on our downstream. If you want it to be chronically correct feel free to merge as a breaking change.
No description provided.