Closed Bug 697795 Opened 8 years ago Closed 8 years ago

Split up remaining TOK_* kinds whose meanings are conditioned on token.t_op

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla11

People

(Reporter: Waldo, Assigned: Waldo)

Details

Attachments

(5 files)

Following up on bug 697297, for the rest of the split-personality token types.
Attachment #570057 - Flags: review?(cdleary)
This also makes a < b < c < d < e not be a single-level parse node tree, as happened to the equality ops.  In retrospect I don't believe that was strictly necessary to do, but it's conceptually simpler, so I'm leaving it this way unless you object.

The <<= >>= >>>= ops grouped under TOK_ASSIGN, which are implicated in the code changed here, will be split up in a later patch.
Attachment #570058 - Flags: review?(cdleary)
Attachment #570059 - Flags: review?(cdleary)
I wonder if the /* super */ comment was obsoleted by my changes to the reserved-word set, or if it bitrotted at some other time...
Attachment #570061 - Flags: review?(cdleary)
This is perhaps the nicest of the batch, because there are a bunch of places in variable declarations and such where we really only ever want '=', and never wanted '|=', '+=', and so on.  These places checked that the parse node sub-op was JSOP_NOP.  Now, TOK_ASSIGN only means '=', so those places don't need to check for the sub-op, and indeed they can even assert that the sub-op is JSOP_NOP.

The names for the +=, -=, etc. tokens are slightly awkward.  I stole my sense of self-approval for the names from <http://msdn.microsoft.com/en-us/library/bb155837.aspx>, so at least someone else thinks addassign and such aren't unreasonable names.  Feel free to suggest something better if you want.  (I did reject "pluseq" and such, despite my sounding them out that way in my head, because I don't think we want to associate "equality" with these operations, since they are in no way equality-related except in spelling.)
Attachment #570062 - Flags: review?(cdleary)
Attachment #570057 - Flags: review?(cdleary) → review+
Attachment #570058 - Flags: review?(cdleary) → review+
Attachment #570059 - Flags: review?(cdleary) → review+
Comment on attachment 570061 [details] [diff] [review]
Split up TOK_PRIMARY

Review of attachment 570061 [details] [diff] [review]:
-----------------------------------------------------------------

I never liked TOK_PRIMARY.

::: js/src/frontend/FoldConstants.cpp
@@ +862,4 @@
>                  pn->become(pn1);
> +                if (pn->isKind(TOK_TRUE)) {
> +                    pn->setKind(TOK_FALSE);
> +                    pn->setOp(JSOP_FALSE);

Do we want a setKindAndOp if we're moving towards this pattern more?
Attachment #570061 - Flags: review?(cdleary) → review+
Attachment #570062 - Flags: review?(cdleary) → review+
You need to log in before you can comment on or make changes to this bug.