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

Implement unary operator execution #321

Closed
10 tasks done
Razican opened this issue Apr 16, 2020 · 4 comments · Fixed by #380 or #388
Closed
10 tasks done

Implement unary operator execution #321

Razican opened this issue Apr 16, 2020 · 4 comments · Fixed by #380 or #388
Labels
enhancement New feature or request good first issue Good for newcomers
Milestone

Comments

@Razican
Copy link
Member

Razican commented Apr 16, 2020

I just noticed that we haven't implemented all unary operators in execution.

  • UnaryOp::IncrementPost (a++)
  • UnaryOp::IncrementPre (++a)
  • UnaryOp::DecrementPost (a--)
  • UnaryOp::DecrementPre (--a)
  • UnaryOp::Minus (-a)
  • UnaryOp::Plus (+a)
  • UnaryOp::Not (!a)
  • UnaryOp::Tilde (~a)
  • UnaryOp::Delete (delete)
  • UnaryOp::Void (void)

This is implemented in boa/src/exec/mod.rs, around line 296.

I think that the "pre" increment/decrement operators, along with the typeof and void operators should be easy to implement, and good for newcomers to Boa.

The "post" increment/decrement operators will be challenging, as we currently always fully evaluate an AST node before continuing, and these need to be evaluated afterwards. The delete operator will be challenging too, I think.

After this is done, in #304 I have implemented some tests that are currently ignored, and we can probably start running them.

@Razican Razican added enhancement New feature or request good first issue Good for newcomers labels Apr 16, 2020
@jasonwilliams
Copy link
Member

Did you want to close jasonwilliams#118 in favour of this?

@Razican
Copy link
Member Author

Razican commented Apr 16, 2020

Did you want to close #118 in favour of this?

Actually, I didn't notice that one, but I think there are two things in there. That issue showed that the parsing was broken. That has been solved. Now the issue is not a bug, it's that we don't have that implemented.

So I would say we should close the issue, as the bug is already fixed, and that we should implement the execution.

I already did a small change in #304, and changed the unreachable!() for an unimplemented!(). It should give a better error message.

@akryvomaz
Copy link
Contributor

I think it makes sense to remove UnaryOp::TypeOf form the list because of the #359

@Razican
Copy link
Member Author

Razican commented May 9, 2020

I think it makes sense to remove UnaryOp::TypeOf form the list because of the #359

Yep, let's remove it!

@Razican Razican added this to the v0.8.0 milestone May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
4 participants