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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

Following up on bug 697297, for the rest of the split-personality token types.

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Split up TOK_RELOP

Comment 2

[Jeff Walden [:Waldo]]

Attachment: Split up TOK_SHOP

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.

Comment 3

[Jeff Walden [:Waldo]]

Attachment: Split up TOK_DIVOP

Comment 4

[Jeff Walden [:Waldo]]

Attachment: Split up TOK_PRIMARY

I wonder if the /* super */ comment was obsoleted by my changes to the reserved-word set, or if it bitrotted at some other time...

Comment 5

[Jeff Walden [:Waldo]]

Attachment: Split up TOK_ASSIGN

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.)

Comment 6

[Chris Leary [:cdleary] (not checking bugmail)]

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?

Comment 7

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/6d6a47da6c5a
https://hg.mozilla.org/mozilla-central/rev/22b33eb2969d
https://hg.mozilla.org/mozilla-central/rev/e80f536a7069
https://hg.mozilla.org/mozilla-central/rev/51039a8be72c
https://hg.mozilla.org/mozilla-central/rev/5271cc9673eb