This will make sure that message tests cover both the parser and preparser
paths, just as we do for parsing-related cctests.
BUG=v8:4372
LOG=n
Review URL: https://codereview.chromium.org/1469383004
Cr-Commit-Position: refs/heads/master@{#32307}
The first bug was that there are two different "initialization positions"
passed into PatternRewriter::DeclareAndInitializeVariables, and we weren't
setting them all properly for this case.
After further code review, it became clear that we weren't even recording
the correct position (the end of the initializer expression).
The combination of those two bugs caused the hole check elimination code
in full-codegen to skip emitting a hole check.
This patch takes care of both of those things. A follow-up will try
to reduce the number of "initializer positions" we track in the
variable declaration code.
R=littledan@chromium.org
BUG=v8:4568
LOG=n
Review URL: https://codereview.chromium.org/1468143004
Cr-Commit-Position: refs/heads/master@{#32237}
For web compat reasons, we support an initializer in the declaration
part of a for-in loop. But we should disallow this for destructured
declarations (just as we do for lexical declarations). In fact, without
disallowing it, we crash.
Also fix up the PreParser to have the same restrictions here as the parser
(the lexical check was missing there), verified by running the message tests
with --min-preparse-length=0.
In fixing the logic I've also cleaned up the code a bit, removing the
only-called-once DeclarationParsingResult::SingleName method.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1471973003
Cr-Commit-Position: refs/heads/master@{#32236}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
Reason for revert:
MSAN errors on arm64: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/5123/
Original issue's description:
> [es6] Implement destructuring binding in try/catch
>
> The approach is to desugar
>
> try { ... }
> catch ({x, y}) { ... }
>
> into
>
> try { ... }
> catch (.catch) {
> let x = .catch.x;
> let y = .catch.y;
> ...
> }
>
> using the PatternRewriter's normal facilities. This has the side benefit
> of throwing the appropriate variable conflict errors for declarations
> made inside the catch block.
>
> No change is made to non-destructured cases, which will hopefully save
> us some work if https://github.com/tc39/ecma262/issues/150 is adopted
> in the spec.
>
> There's one big problem with this patch, which is a lack of PreParser
> support for the redeclaration errors. But it seems we're already lacking
> good PreParser support for such errors, so I'm not sure that should
> block this moving forward.
>
> BUG=v8:811
> LOG=y
>
> Committed: https://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba
> Cr-Commit-Position: refs/heads/master@{#31797}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811
Review URL: https://codereview.chromium.org/1408063013
Cr-Commit-Position: refs/heads/master@{#31798}
The approach is to desugar
try { ... }
catch ({x, y}) { ... }
into
try { ... }
catch (.catch) {
let x = .catch.x;
let y = .catch.y;
...
}
using the PatternRewriter's normal facilities. This has the side benefit
of throwing the appropriate variable conflict errors for declarations
made inside the catch block.
No change is made to non-destructured cases, which will hopefully save
us some work if https://github.com/tc39/ecma262/issues/150 is adopted
in the spec.
There's one big problem with this patch, which is a lack of PreParser
support for the redeclaration errors. But it seems we're already lacking
good PreParser support for such errors, so I'm not sure that should
block this moving forward.
BUG=v8:811
LOG=y
Review URL: https://codereview.chromium.org/1417483014
Cr-Commit-Position: refs/heads/master@{#31797}
When the checker was added prohibiting lexical binding called let,
certain error propagation was not implemented properly. This patch
fixes that issue, which fixes error checking for cases such as
let [let]
BUG=v8:4403
R=adamk
LOG=N
Review URL: https://codereview.chromium.org/1409613003
Cr-Commit-Position: refs/heads/master@{#31289}
An identifier may be parsed in an object literal like {let}, but
this was previously left out of lexical name checking. This patch
adds that check to prohibit code like
let {let} = {let: 1}
BUG=v8:4403
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1401253003
Cr-Commit-Position: refs/heads/master@{#31278}
This patch prohibits lexical bindings from being called 'let', even in
sloppy mode, following the ES2015 specification. The change affects
multiple cases of lexical bindings, including simple let/const declarations
and both kinds of for loops. var and legacy const bindings still permit
the name to be let, including in destructuring cases. Tests are added to
verify, though some cases are commented out since they led to (pre-existing)
crashes.
BUG=v8:4403
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1371263003
Cr-Commit-Position: refs/heads/master@{#31115}
Reason for revert:
Prime suspect in breakage of V8 Linux -- no snap
Original issue's description:
> [swarming] Isolate v8 testing.
>
> Add gyp support and isolates for default test suites.
> Add two default isolates, one (default) for using the
> test suite collection we call "default" on the bots. One
> (developer_default) for also supporting the way developers
> call the driver (i.e. without argument, which includes
> the unittests).
>
> BUG=chromium:535160
> LOG=n
>
> Committed: https://crrev.com/9bd83f58f29ab0c7c5b71b00bcb1df3a9e641f05
> Cr-Commit-Position: refs/heads/master@{#31081}
TBR=tandrii@chromium.org,jochen@chromium.org,maruel@chromium.org,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535160
Review URL: https://codereview.chromium.org/1370993008
Cr-Commit-Position: refs/heads/master@{#31084}
Add gyp support and isolates for default test suites.
Add two default isolates, one (default) for using the
test suite collection we call "default" on the bots. One
(developer_default) for also supporting the way developers
call the driver (i.e. without argument, which includes
the unittests).
BUG=chromium:535160
LOG=n
Review URL: https://codereview.chromium.org/1380593002
Cr-Commit-Position: refs/heads/master@{#31081}
Arrow functions have been enabled by default since the 4.5 branch.
Review URL: https://codereview.chromium.org/1373633002
Cr-Commit-Position: refs/heads/master@{#31031}
Now run-tests.py understands "suite/foo/bar" with forward slashes for
command-line test selection on all test suites on all platforms.
Previously, file-based suites like mjsunit also accepted "mjsunit/foo\bar";
that behavior is sacrificed here in favor of unification. For the cctest
suite, OTOH, it wasn't possible on Windows to select specific tests at all.
Original review: https://codereview.chromium.org/1348653003/
This reverts commit 5f44a91059.
NOTRY=true
Review URL: https://codereview.chromium.org/1356613002
Cr-Commit-Position: refs/heads/master@{#30798}
Reason for revert:
mozilla tests are failing on Windows
Original issue's description:
> [test] Fix cctest path separators on Windows
>
> Now run-tests.py understands "suite/foo/bar" with forward slashes for
> command-line test selection on all test suites on all platforms.
>
> Previously, file-based suites like mjsunit also accepted "mjsunit/foo\bar";
> that behavior is sacrificed here in favor of unification. For the cctest
> suite, OTOH, it wasn't possible on Windows to select specific tests at all.
>
> Committed: https://crrev.com/b36cfdb39ae648b49a1396c4f669df9b1f57996c
> Cr-Commit-Position: refs/heads/master@{#30794}
TBR=machenbach@google.com,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1349163002
Cr-Commit-Position: refs/heads/master@{#30795}
Now run-tests.py understands "suite/foo/bar" with forward slashes for
command-line test selection on all test suites on all platforms.
Previously, file-based suites like mjsunit also accepted "mjsunit/foo\bar";
that behavior is sacrificed here in favor of unification. For the cctest
suite, OTOH, it wasn't possible on Windows to select specific tests at all.
Review URL: https://codereview.chromium.org/1348653003
Cr-Commit-Position: refs/heads/master@{#30794}
This switches Isolate::ComputeLocation to use baseline code when
computing message locations. This unifies locations between optimized
and non-optimized code by always going through the FrameSummary for
location computation.
R=bmeurer@chromium.org
TEST=message/regress/regress-4266
BUG=v8:4266
LOG=n
Review URL: https://codereview.chromium.org/1331603002
Cr-Commit-Position: refs/heads/master@{#30635}
Second item in section 13.7.5.1 states that the error should be a
SyntaxError, when previously CheckAndRewriteReferenceExpression
would always emit a ReferenceError.
BUG=v8:4373
R=adamk, rossberg
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1292393002
Cr-Commit-Position: refs/heads/master@{#30184}
In doing so, fix calls CheckAndRewriteReferenceExpression to take proper
start and end positions (instead of just pointing at the first token in
the LHS expression).
BUG=v8:4370
LOG=n
Review URL: https://codereview.chromium.org/1290013002
Cr-Commit-Position: refs/heads/master@{#30166}
Duplicate parameters are banned both overall in strict mode and also
in arrow functions. Our error message for both cases blamed strict
mode, which is confusing. This patch fixes the message to point to
arrow functions as a possible source as well.
R=wingo, adamk
LOG=N
Review URL: https://codereview.chromium.org/1236863008
Cr-Commit-Position: refs/heads/master@{#29662}
This patch includes the following changes.
1, Enable the turbofan backend support for X87 platform. It depends on previous CL: 3fdfebd26.
2, Enable the test cases which are disabled because turbofan for X87 was not enabled.
BUG=v8:4135
LOG=N
Review URL: https://codereview.chromium.org/1179763004
Cr-Commit-Position: refs/heads/master@{#29049}
The strong-object-set-proto test cases will throw one expected exception
and the exception message should include the source position in the JS
file. But crankshaft compiler does not generate the source position for
it when creating the flow graph by default. The source position information
is always zero. So it failed when comparing with the reference file.
If we use crankshaft compiler on IA32 platform to run this test case, it
has the same failure.
we will open these test case for x87 once turbofan for X87 is enabled.
BUG=
Review URL: https://codereview.chromium.org/1179763003
Cr-Commit-Position: refs/heads/master@{#29003}
A mistake in a recent CL has messed up the error messages for strong object
semantics.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1166433007
Cr-Commit-Position: refs/heads/master@{#28741}
The overwrite-builtins test cases will throw one expected exception
and the exception message should include the source position in the JS
file. But crankshaft compiler does not generate the source position for
it when creating the flow graph by default. The source position information
is always zero. So it failed when comparing with the reference file.
If we use crankshaft compiler on IA32 platform to run this test case, it
has the same failure.
BUG=
Review URL: https://codereview.chromium.org/1086503002
Cr-Commit-Position: refs/heads/master@{#27807}
This makes the compilers agree on the source position of a message
generated by "throw new Error()", it points to the beginning of the
throw directive.
R=titzer@chromium.org
TEST=message/regress/regress-3995
BUG=v8:3995
LOG=N
Review URL: https://codereview.chromium.org/1049703002
Cr-Commit-Position: refs/heads/master@{#27775}
This commit is a precursor to making lazy arrow function parsing use
similar logic to function(){} argument parsing.
R=arv@chromium.org
BUG=4020
LOG=N
Review URL: https://codereview.chromium.org/1078093002
Cr-Commit-Position: refs/heads/master@{#27773}
The ES6 grammar forbids the initialization of variable declarations in IterationStatements.
This CL will report `for (var x = y in z)` as a SyntaxError in strict mode (as done in JSC). It is possible that this could break sites in sloppy mode, and so that change can wait.
BUG=
R=
LOG=N
Review URL: https://codereview.chromium.org/1033823002
Cr-Commit-Position: refs/heads/master@{#27639}
