Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

experiment(ast): rework enum of structures #2877

Conversation

rzvxa
Copy link
Collaborator

@rzvxa rzvxa commented Mar 31, 2024

As asked by @Boshen in this PR.

Copy link
Collaborator Author

rzvxa commented Mar 31, 2024

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

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

Join @rzvxa and the rest of your teammates on Graphite Graphite

@github-actions github-actions bot added A-linter Area - Linter A-semantic Area - Semantic A-ast Area - AST labels Mar 31, 2024
@rzvxa rzvxa changed the title experiment(ast): rework enum of structures. experiment(ast): rework enum of structures Mar 31, 2024
@github-actions github-actions bot added A-parser Area - Parser A-codegen Area - Code Generation labels Mar 31, 2024
@github-actions github-actions bot added the A-transformer Area - Transformer / Transpiler label Mar 31, 2024
@rzvxa rzvxa marked this pull request as ready for review March 31, 2024 16:41
@rzvxa
Copy link
Collaborator Author

rzvxa commented Mar 31, 2024

It won't get merged, Instead, we will close this one in favor of #2876.

@rzvxa rzvxa requested a review from Boshen March 31, 2024 16:42
let id = expr.ast_node_id().unwrap();

assert_eq!(id, AstNodeId::new(6));
assert_eq!(self.0.nodes().ancestors(id).collect::<Vec<_>>(), vec![6, 5, 4, 3, 2, 1, 0]);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Boshen The current node is set as its own first ancestor, Is that the correct behavior? I suspect that it is happening regardless of my changes since I didn't touch any of the tests and they all are passing. But other than this weird observation everything is working as we desire.

If this behavior is fishy let me know so I can compare it with the main branch.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into the implementation and it seems fine to me, If that's the case then this experiment is ready for comments.

Dunqing pushed a commit that referenced this pull request Apr 1, 2024
…re. (#2881)

This would fix the issue found in #2877,

As it is right now, the `FinallyClause` gets visited 2 times, once as
the Finally and once as a block.

This PR addresses this issue by making the `visit_finally_clause` method
visit the body statements instead of visiting the block itself. Now it
works similar to the `CatchClause`.
@Boshen Boshen marked this pull request as draft April 3, 2024 02:43
@Boshen Boshen closed this May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ast Area - AST A-codegen Area - Code Generation A-linter Area - Linter A-parser Area - Parser A-semantic Area - Semantic A-transformer Area - Transformer / Transpiler
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants