Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla11

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Waldo, Assigned: Waldo)

Tracking

Trunk
mozilla11
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

Following up on bug 697297, for the rest of the split-personality token types.
Created attachment 570057 [details] [diff] [review]
Split up TOK_RELOP
Attachment #570057 - Flags: review?(cdleary)
Created attachment 570058 [details] [diff] [review]
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.
Attachment #570058 - Flags: review?(cdleary)
Created attachment 570059 [details] [diff] [review]
Split up TOK_DIVOP
Attachment #570059 - Flags: review?(cdleary)
Created attachment 570061 [details] [diff] [review]
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...
Attachment #570061 - Flags: review?(cdleary)
Created attachment 570062 [details] [diff] [review]
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.)
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+
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
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
You need to log in before you can comment on or make changes to this bug.