I didn't really intend to check them in; they slipped into the patch and slipped past review. But they fail on browser startup. They should probably pass, so I want to look into it, but I'm commenting them out for now.
Created attachment 568792 [details] [diff] [review] v1
Assignee: general → jorendorff
Attachment #568792 - Flags: review?(luke)
Since you have left some uses of newBinaryOrAppend, could you explain what it is about these particular uses that broke this condition? It doesn't leap out at me.
(In reply to Luke Wagner [:luke] from comment #3) > Since you have left some uses of newBinaryOrAppend, could you explain what > it is about these particular uses that broke this condition? It doesn't > leap out at me. The assertion is that the lhs and rhs don't overlap. In all of the other calls to newBinaryOrAppend, lhs and rhs represent two different expressions that appear in the source, in the same order, with an operator token in between. So they are guaranteed not to overlap. (Most of those cases are for mulExpr1, addExpr1, etc. and are straightforward. The oddball is the destructuring case in Parser::variables. There lhs is a destructuring target, which we parse as a primaryExpr and then verify with CheckDestructuring, and rhs is the init-expression. So again, no overlap can occur, and newBinaryOrAppend is fine.)
Comment on attachment 568792 [details] [diff] [review] v1 Ah, thanks.
Attachment #568792 - Flags: review?(luke) → review+
It think, I needs this for my patch in Bug 715359, unless I do it in some other way.
Philor backed bug 695922, bug 678086, and bug 719841 out of mozilla-inbound for causing Tp crashes. https://hg.mozilla.org/mozilla-central/rev/117f2280bd37
Found the bug. See bug 678086 comment 7.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.