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 += functionality #225

Merged
merged 5 commits into from
Nov 13, 2024
Merged

Add += functionality #225

merged 5 commits into from
Nov 13, 2024

Conversation

bufferhe4d
Copy link
Contributor

Attempt to resolve #175

@@ -389,6 +389,112 @@ impl<B: Backend> TypeChecker<B> {
| Op2::Division
| Op2::BoolAnd
| Op2::BoolOr => lhs_node.typ,
Op2::PlusEqual => {
// todo: better way to do this instead of copying assignment logic?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here I copied the same logic from ExprKind::Assignment. I am not sure if this is the correct way to do it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, this looks redundant to the assignment.

One alternative may be to transform the expression from lhs += rhs to lhs = lhs + rhs. The transformation would need to be before the type checking phase. Maybe this can happen in the name resolution pipeline:

ExprKind::BinaryOp {

@mimoo wdyt?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@bufferhe4d
I just had a discussion with @mimoo. We see the += more like a shortcut instead of new operator. We thought it would be better to implement the transformation as described above at the name resolution. That would simplify the PR and avoid the redundancy in the type checking.

Please feel free to comment if you have any questions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright, this looks like a much more elegant approach. Thanks. Few questions:

  1. If we decide to do it under name resolution, it feels like either we need to keep a new operator under Op2 to recognize this op and resolve. Or we need a new ExprKind (could be called AugmentedAssignment). I guess you would prefer the latter to get rid of defining a new operation under Op2 Right?
  2. If we also wouldn't prefer to create a new ExprKind . Shall I attempt to make this resolution directly in parse_rhs ?
    fn parse_rhs(self, ctx: &mut ParserCtx, tokens: &mut Tokens) -> Result<Expr> {

Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be better if we can avoid a new Op2 for this case.

So looks like the parse_rhs is the way to go. That is a great insight @bufferhe4d 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright, here is my new attempt. I also went ahead and implemented -= and *= inside parse_rhs, added some tests as well. I hope this works as intended now. Please let me know if anything is problematic. Thanks.

Copy link
Collaborator

@katat katat left a comment

Choose a reason for hiding this comment

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

Looks great to me!

@katat
Copy link
Collaborator

katat commented Nov 12, 2024

There are CI errors on formatting. You may want to run cargo fmt to format the code.

@bufferhe4d
Copy link
Contributor Author

There are CI errors on formatting. You may want to run cargo fmt to format the code.

Indeed, should be good to go now.

@katat katat merged commit b17ea20 into zksecurity:main Nov 13, 2024
1 check passed
@katat
Copy link
Collaborator

katat commented Nov 13, 2024

Merged. Thanks again!

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.

+= operator
2 participants