Could you also add a description to describe exactly what is allowed now;
it's
sort of tedious to infer as the negation of the union of the added errors :)
(I'm also slightly skeptical that there are no tests that assert that some
stuff
*is* allowed; because without such a test this CL can overshoot, i.e., it
could
theoretically produce errors always when it sees super or this, and we
wouldn't
notice.)
https://codereview.chromium.org/1024063002/diff/20001/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):
https://codereview.chromium.org/1024063002/diff/20001/test/cctest/test-parsing.cc#newcode5591
test/cctest/test-parsing.cc:5591: "class C extends Object {
constructor() { (this); } }",
I'm not sure if this test is testing what it looks like at the first
glance.. Is parsing failing for all of these because there's no super
call? So strong_super_call_misplaced? Or is it failing because of
strong_constructor_this, or is it mixed (the this.a = 0 failing because
of the former, at least)?
For the "malformed this expression" case the interesting tests would be
like:
super()
if (1) this.a = 0;
etc., right?
I think it would be worthwhile to split this test into 2 cases, where
the first set is failing because there's no super call (even though the
this assignment is valid) -- you can put the super call into
context_data, so, test that it's succeeding w/
context_data_with_super_call, but failing w/
context_data_without_super_call. The second set would then be failing
with both contexts, because the assignment is malformed.
https://codereview.chromium.org/1024063002/
--
--
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.
