On 2015/08/31 11:22:53, conradw wrote:
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).
Do you expect the same error for these productions?
({x.y, 2});
({x.y, 2}) => 45;
I would expect the first to give:
({x.y, 2});
^ Unexpected token: 2
and the second:
({x.y, 2}) => 45;
^ Unexpected token: .
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.
