On 2015/08/28 09:54:13, wingo wrote:
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h
File src/expression-classifier.h (right):
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h#newcode158
src/expression-classifier.h:158: void RecordPatternError(const
Scanner::Location& loc,
On 2015/08/27 15:32:24, conradw wrote:
> I was thinking it might be possible to eliminate/combine the
> assignment_pattern_error_ object, since every time
assignment_pattern_error_
is
> set, binding_pattern_error_ is set identically. From what you're saying,
there
> would still need to be two separate bits in invalid_productions_
however.
Not sure that this works. Consider:
({x.y, 2}) => 45
We're going to want to raise the binding pattern error, not the assignment
pattern error.
My impression was that this is the reason that {assignment, binding}_pattern
errors are both recorded in the case of a potential assignment pattern
error.
Since the message is identical, I feel like it's possible to eliminate a
copy of
the error object in this case (as long as the distinction of validating
specifically for an assignment pattern error, for the case caitp mentioned
above, still exists in the invalid_productions_ pseudo-bitfield).
https://codereview.chromium.org/1309813007/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
