-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Simplify String rule in parser #2805
Conversation
Use a StringStart component that is either FORMAT QQSTRING_START or QQSTRING_START instead of having two similar rules for String. This is simpler and avoids having to use an untyped mid-rule action component to copy FORMAT at the top of the stack before QQString, and having to use jv_free($<literal>3) instead of jv_free($1) just to make bison not complain about the "unused" mid-rule component.
c0de8fb
to
7c6dd9a
Compare
My first thought of skimming the rules is that including the format prefix in String is an unintended accident. |
Why should you only be allowed to use a different format for a string literal in an expression, and not when using a string literal in a object constructor as key, or as |
I like this. It's easier to understand. |
LGTM. I really like this simplification. I'm not seeing what it might break either.
So I think this is ready, unless there's any other objections. Changing nothing in the language while simplifying the parser is a win. |
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.
Okay. Looks good.
Thanks! |
Use a
StringStart
component that is eitherFORMAT QQSTRING_START
orQQSTRING_START
instead of having two similar rules forString
.This is simpler and avoids having to use an untyped mid-rule action component to copy
FORMAT
at the top of the stack beforeQQString
, and having to usejv_free($<literal>3)
instead ofjv_free($1)
just to make bison not complain about the "unused" mid-rule component.