Closed
Bug 697795
Opened 13 years ago
Closed 13 years ago
Split up remaining TOK_* kinds whose meanings are conditioned on token.t_op
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla11
People
(Reporter: Waldo, Assigned: Waldo)
Details
Attachments
(5 files)
5.87 KB,
patch
|
cdleary
:
review+
|
Details | Diff | Splinter Review |
6.37 KB,
patch
|
cdleary
:
review+
|
Details | Diff | Splinter Review |
4.45 KB,
patch
|
cdleary
:
review+
|
Details | Diff | Splinter Review |
12.65 KB,
patch
|
cdleary
:
review+
|
Details | Diff | Splinter Review |
17.28 KB,
patch
|
cdleary
:
review+
|
Details | Diff | Splinter Review |
Following up on bug 697297, for the rest of the split-personality token types.
Assignee | ||
Comment 1•13 years ago
|
||
Attachment #570057 -
Flags: review?(cdleary)
Assignee | ||
Comment 2•13 years ago
|
||
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)
Assignee | ||
Comment 3•13 years ago
|
||
Attachment #570059 -
Flags: review?(cdleary)
Assignee | ||
Comment 4•13 years ago
|
||
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)
Assignee | ||
Comment 5•13 years ago
|
||
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)
Updated•13 years ago
|
Attachment #570057 -
Flags: review?(cdleary) → review+
Updated•13 years ago
|
Attachment #570058 -
Flags: review?(cdleary) → review+
Updated•13 years ago
|
Attachment #570059 -
Flags: review?(cdleary) → review+
Comment 6•13 years ago
|
||
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+
Updated•13 years ago
|
Attachment #570062 -
Flags: review?(cdleary) → review+
Comment 7•13 years ago
|
||
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
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
You need to log in
before you can comment on or make changes to this bug.
Description
•