-
Notifications
You must be signed in to change notification settings - Fork 464
add shift(<<
, >>
, >>>
) operator
#7183
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
Conversation
Hi @gwansikk! Would be great to get this PR merged - do you have time to pick up work on it again? |
of course! I had been missing it due to personal matters. I will try to work on it as soon as possible. |
This now has conflicts because I removed |
Got it! I’ll take care of it and aim to wrap up the task within this week. Apologies for the delay(this PR work). |
This task is causing more issues than expected (JSX, type generic precedence, and syntax), so it may be delayed. I’ll try to complete it as soon as possible. |
Yes, this turned out to be much harder than I expected. JSX syntax consumes In the last pair session, we found that modifying the core scanner loop was not working, so we explored converting it to a virtual token in the middle of the parser. Mutations fooled us. Since it is scanner logic anyway, we discussed adding a custom method to the scanner instead of the parser. |
@gwansikk fixed the implementation. I realized I had been misguided, and your initial approach was almost close. |
5d308e7 removes additional parens, which makes no difference in behavior. It makes the output more compact but makes a readability issue in some nested structures. Maybe we can put parens again depending on the expression depth. |
Thank you for your work @gwansikk @cometkim!
Not saying that we need to do it the same way, but I had a look at what prettier does in some of the situations where our code formatting changes with this PR. |
That's good to know. They always add parens when it is mixed with bitwise operators. I thought it might be too much since we have Let's split the output change and review it separately in another PR. |
Done |
Co-authored-by: Hyeseong Kim <[email protected]>
I looked back at the last session with Gwansik and realized that, I had misguided him by simply misunderstanding a particular syntx error. Gwansik's initial approach was almost close. Co-authored-by: gwansikk <[email protected]>
This reverts commit 5d308e7.
@cknitt Can we merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
related: #7171
ref: