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

feat(regular_expression): add terms visitor to pattern #5951

Conversation

camchenry
Copy link
Contributor

@camchenry camchenry commented Sep 21, 2024

To make it easier to iterate over the nodes in the regex AST, I attempted to add a pseudo-visitor method for patterns

Copy link

graphite-app bot commented Sep 21, 2024

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-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.

Copy link
Contributor Author

camchenry commented Sep 21, 2024

Copy link

codspeed-hq bot commented Sep 21, 2024

CodSpeed Performance Report

Merging #5951 will not alter performance

Comparing 09-21-feat_regular_expression_add_terms_visitor_to_pattern (cfb8510) with main (05f592b)

Summary

✅ 29 untouched benchmarks

@leaysgur
Copy link
Contributor

@DonIsaac I am not familiar with this area...! 😅

Should these be handwritten? Or we need some updates for tasks/ast_tools?

@camchenry
Copy link
Contributor Author

camchenry commented Sep 22, 2024

I feel like this might be the wrong implementation, but we probably do need some sort of regular expression AST visitor. I think a better approach here would be to create a generic AST visitor that can visit every node type in the Regex: Term, Disjunction, Alternative, etc.

I'm going to mark this as draft for now

@camchenry camchenry marked this pull request as draft September 22, 2024 01:53
@leaysgur
Copy link
Contributor

create a generic AST visitor that can visit every node type

I agree.

For the main oxc_ast ASTs, it seems adding #[ast(visit)] instructs tasks/ast_tools to automatically generate the visit_ implementation (sorry, maybe I'm wrong).

However, I don't know the details of how it works or whether we should do the same here.

@Boshen Would you please help me to review? 🙏🏻

@Boshen
Copy link
Member

Boshen commented Sep 22, 2024

We can always start with a manual one to test the water, and then migrate to ast_tools.

@leaysgur
Copy link
Contributor

@camchenry If that's the case, I think there's no problem.

Just 1 point, I think it would be nice to separate the file as visit.rs with comments referring to ast_tools.

@camchenry
Copy link
Contributor Author

closing this in favor of #6055, which is the better implementation I think

@camchenry camchenry closed this Sep 25, 2024
Boshen pushed a commit that referenced this pull request Sep 26, 2024
…ST (#6055)

- resolves #5977
- supersedes #5951

To facilitate easier traversal of the Regex AST, this PR defines a `Visit` trait with default implementations that will walk the entirety of the Regex AST. Methods in the `Visit` trait can be overridden with custom implementations to do things like analyzing only certain nodes in a regular expression, which will be useful for regex-related `oxc_linter` rules.

In the future, we should consider automatically generating this code as it is very repetitive, but for now a handwritten visitor is sufficient.
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.

3 participants