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

Add manually implemented AST visitor #758

Closed
wants to merge 5 commits into from

Conversation

tustvold
Copy link
Contributor

Related to #78, #114, #601

This implements a basic AST visitor. I'm not convinced this is the best way to implement this, as it is relatively fragile, but I wanted to get something up to acts as a comparison point

@coveralls
Copy link

Pull Request Test Coverage Report for Build 3685169537

  • 12 of 554 (2.17%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-3.1%) to 83.174%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/ast/value.rs 0 2 0.0%
src/ast/ddl.rs 0 49 0.0%
src/ast/query.rs 12 152 7.89%
src/ast/mod.rs 0 351 0.0%
Totals Coverage Status
Change from base Build 3641238188: -3.1%
Covered Lines: 12541
Relevant Lines: 15078

💛 - Coveralls

@alamb
Copy link
Contributor

alamb commented Dec 14, 2022

So what I would really like to do is to figure out some way to automatically generate this code (like using rustc_parse or something) and then automatically generate visitors (and mutators) as part of the build.rs system somehow

// limitations under the License.

use crate::ast::{Expr, ObjectName, Statement};
use core::ops::ControlFlow;
Copy link
Contributor

Choose a reason for hiding this comment

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

TIL: ControlFlow

@tustvold
Copy link
Contributor Author

So what I would really like to do is to figure out some way to automatically generate this code

I'll have a play with what a proc-macro / codegen setup looks like

@tustvold
Copy link
Contributor Author

I think the approach in #765 is much more maintainable that this, which I think would be non-trivial to maintain and would act as a potential barrier to contribution

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