Statement positions should overwrite expression positions if they
have the same bytecode offset.

R=mstarzinger@chromium.org, vogelheim@chromium.org
BUG=v8:4680,v8:4689
LOG=N

Review URL: https://codereview.chromium.org/1855913002

Cr-Commit-Position: refs/heads/master@{#35236}

The parser uses a try-catch in order to record when the client of an iterator
throws.  The exception then used to get rethrown via 'throw', which
unfortunately resulted in the original exception message object getting
overwritten.

This CL solves this as follows:
- add a clear_pending_message flag to TryCatchStatement (set to true in normal
  cases),
- set clear_pending_message to false for the TryCatchStatement used in iterator
  finalization
- change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
  only when the flag is set,
- replace 'throw' with '%ReThrow' in the iterator finalization code, thus
  reusing the (not-cleared) pending message

R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4875
LOG=n

Review URL: https://codereview.chromium.org/1842953003

Cr-Commit-Position: refs/heads/master@{#35226}

Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.

In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.

Also gone are any tests which relied on legacy const declarations.

Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.

Review URL: https://codereview.chromium.org/1819123002

Cr-Commit-Position: refs/heads/master@{#35002}

Enables the Scanner to provide a better error message when errors occur
in escape sequences, numbers, strings, etc.

BUG=v8:4829, v8:3230
LOG=N
R=adamk@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1793913002

Cr-Commit-Position: refs/heads/master@{#34966}

This rebaselines all our internal tests for error messages thrown by the
implementation of 'instanceof' to the new ES6 semantics. It also applies
a minor rephrasing to the messages in question.

R=rossberg@chromium.org
BUG=v8:4447
LOG=n

Review URL: https://codereview.chromium.org/1822663002

Cr-Commit-Position: refs/heads/master@{#34940}

We need one message in case the function is not an object, and
another if it was an object but not callable.

R=mstarzinger@chromium.org, rossberg@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1814823002

Cr-Commit-Position: refs/heads/master@{#34883}

It was never being set to false in production (though it was in test-parsing.cc,
due to that test having its own flag-setting logic).

Review URL: https://codereview.chromium.org/1815033002

Cr-Commit-Position: refs/heads/master@{#34878}

Report correct error message when a scanner error occurs while parsing a tagged
template within an expression context.

BUG=v8:4829, v8:3230
LOG=N
R=adamk@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1806063002

Cr-Commit-Position: refs/heads/master@{#34839}

test262 "negative" test expectations list which exception is thrown. The ES2017
draft specification is very specific about which exception class is thrown
from which path, and V8 works hard to be correct with respect to that spec.

Previously, the test262 test runner would accept any nonzero status code,
such as from a crash, or a FAIL printed out, for a negative test. This
patch makes negative tests check for the right answer using a quick-and-dirty
parsing of the exception printing from d8 to find the exception class.
It invokes d8 in a way to get a status code of 0 from thrown exceptions
so that 'negative' tests aren't actually implemented by negating the output.

Amazingly, this didn't catch any test262 failures, but I verified the extra
checking interactively by changing a negative test to expect a different type
and saw it fail.

BUG=v8:4803
R=machenbach
LOG=Y

Review URL: https://codereview.chromium.org/1766503002

Cr-Commit-Position: refs/heads/master@{#34763}

This moves the last remaining JS file based tests out of the "preparser"
suite. The tests in question all are expected to parse normally and not
throw any exception. This also deprecates the ability of the test suite
to run anything else outside Python templated tests.

R=adamk@chromium.org
TEST=preparser

Review URL: https://codereview.chromium.org/1782173005

Cr-Commit-Position: refs/heads/master@{#34753}

This converts another test case that is expected to throw a TypeError
but no SyntaxError to have better test coverage (exact message is being
checked now).

R=machenbach@chromium.org
TEST=message,preparser

Review URL: https://codereview.chromium.org/1786623002

Cr-Commit-Position: refs/heads/master@{#34715}

This converts existing "preparser" tests that expect a certain exception
message to be produced into "message" tests. Thereby we get much better
coverage because the former test suite degraded by now to just check
whether each test case threw or not, the exception message was not being
checked at all.

This also deprecates the ability of "preparser" to specify that single
test cases based on JS files are expected to throw, "messages" is far
superior, use that test suite instead.

R=machenbach@chromium.org
TEST=message,preparser

Review URL: https://codereview.chromium.org/1784013003

Cr-Commit-Position: refs/heads/master@{#34713}

This also runs the message test suite against Ignition. By now most of
the source positions (and exception messages) are accurate, the failing
ones have been blacklisted.

R=machenbach@chromium.org

Review URL: https://codereview.chromium.org/1783773003

Cr-Commit-Position: refs/heads/master@{#34708}

These flags have been on by default since version 4.9, which has been
in stable Chrome for over a week now, demonstrating that they're
here to stay.

Also moved the tests out of harmony/ and into es6/.

Review URL: https://codereview.chromium.org/1776683003

Cr-Commit-Position: refs/heads/master@{#34692}

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

Review URL: https://codereview.chromium.org/1734243004

Cr-Commit-Position: refs/heads/master@{#34333}

BUG=v8:4756
LOG=N
R=adamk@chromium.org, littledan@chromium.org, wingo@igalia.com

Review URL: https://codereview.chromium.org/1700123003

Cr-Commit-Position: refs/heads/master@{#34050}

This avoids spending lots of time in Scope::RemoveUnresolved for very long
variable declaration lists.

BUG=v8:4699
LOG=n

Review URL: https://codereview.chromium.org/1655313003

Cr-Commit-Position: refs/heads/master@{#34047}

Based on vogelheim's CL at https://codereview.chromium.org/1657783002/

BUG=chromium:582626, v8:2700
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, vogelheim@chromium.org

Review URL: https://codereview.chromium.org/1656993002

Cr-Commit-Position: refs/heads/master@{#33651}

Reland of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #1 id:1 of https://codereview.chromium.org/1565263002/ )

Reason for revert:
Crash fixed by https://codereview.chromium.org/1564923007

Original issue's description:
> Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )
>
> Reason for revert:
> Causes frequent crashes in Canary: chromium:537816
>
> Original issue's description:
> > Ship ES2015 sloppy-mode function hoisting, let, class
> >
> > This patch doesn't ship all features of ES2015 variable/scoping
> > changes, notably omitting the removal of legacy const. I think
> > function hoisting, let and class in sloppy mode can stand to
> > themselves as a package, and the legacy const change is much
> > riskier and more likely to be reverted, so my intention is to
> > pursue those as a separate, follow-on patch.
> >
> > R=adamk@chromium.org
> > BUG=v8:4285,v8:3305
> > LOG=Y
> > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> >
> > Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> > Cr-Commit-Position: refs/heads/master@{#33133}
>
> TBR=adamk@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:4285,v8:3305,chromium:537816
> LOG=Y
>
> Committed: https://crrev.com/adac5956c6216056a211cfaa460a00ac1500d8f8
> Cr-Commit-Position: refs/heads/master@{#33162}

TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285,v8:3305,chromium:537816

Review URL: https://codereview.chromium.org/1571793002

Cr-Commit-Position: refs/heads/master@{#33189}

Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )

Reason for revert:
Causes frequent crashes in Canary: chromium:537816

Original issue's description:
> Ship ES2015 sloppy-mode function hoisting, let, class
>
> This patch doesn't ship all features of ES2015 variable/scoping
> changes, notably omitting the removal of legacy const. I think
> function hoisting, let and class in sloppy mode can stand to
> themselves as a package, and the legacy const change is much
> riskier and more likely to be reverted, so my intention is to
> pursue those as a separate, follow-on patch.
>
> R=adamk@chromium.org
> BUG=v8:4285,v8:3305
> LOG=Y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> Cr-Commit-Position: refs/heads/master@{#33133}

TBR=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4285,v8:3305,chromium:537816
LOG=Y

Review URL: https://codereview.chromium.org/1565263002

Cr-Commit-Position: refs/heads/master@{#33162}

This patch doesn't ship all features of ES2015 variable/scoping
changes, notably omitting the removal of legacy const. I think
function hoisting, let and class in sloppy mode can stand to
themselves as a package, and the legacy const change is much
riskier and more likely to be reverted, so my intention is to
pursue those as a separate, follow-on patch.

R=adamk@chromium.org
BUG=v8:4285,v8:3305
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1551443002

Cr-Commit-Position: refs/heads/master@{#33133}

These constructors always go through C++ at least twice anyway, so
there's not really a point in trying to implement them in JavaScript.

R=yangguo@chromium.org
BUG=chromium:535408
LOG=n

Review URL: https://codereview.chromium.org/1548623002

Cr-Commit-Position: refs/heads/master@{#33012}

It shipped in Chrome 47.

Review URL: https://codereview.chromium.org/1519073004

Cr-Commit-Position: refs/heads/master@{#32816}

BUG=v8:3983
LOG=N
R=wingo@igalia.com, littledan@chromium.org

Review URL: https://codereview.chromium.org/1437803004

Cr-Commit-Position: refs/heads/master@{#32682}

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}

http://crrev.com/80a1e004f4ef619b54a2d87bf2108719a8411860 was reverted
due to a Blink test failure. That test has been marked as failing on
the Blink side in https://chromium.googlesource.com/chromium/src/+/ac11c6df133.

BUG=v8:811
LOG=y
TBR=rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1409093005

Cr-Commit-Position: refs/heads/master@{#31842}

Revert of Revert "Revert of [es6] Implement destructuring binding in try/catch" (patchset #2 id:20001 of https://codereview.chromium.org/1411323008/ )

Reason for revert:
[Sheriff] Breaks a layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/2750

Please request rebase upstream first if intended.

Original issue's description:
> Revert "Revert of [es6] Implement destructuring binding in try/catch"
>
> Reland try/catch destructuring with a fix for the MemorySanitizer failure:
> initialization_pos needs to be initialized in the DeclarationDescriptor.
>
> This is a one line fix to http://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba
>
> BUG=v8:811
> LOG=y
>
> Committed: https://crrev.com/80a1e004f4ef619b54a2d87bf2108719a8411860
> Cr-Commit-Position: refs/heads/master@{#31834}

TBR=littledan@chromium.org,rossberg@chromium.org,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811

Review URL: https://codereview.chromium.org/1421193006

Cr-Commit-Position: refs/heads/master@{#31840}

Reland try/catch destructuring with a fix for the MemorySanitizer failure:
initialization_pos needs to be initialized in the DeclarationDescriptor.

This is a one line fix to http://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba

BUG=v8:811
LOG=y

Review URL: https://codereview.chromium.org/1411323008

Cr-Commit-Position: refs/heads/master@{#31834}

Emit an early error when BindingPatterns are used in a VariableDeclaration
or LexicalBinding without an Initializer.

BUG=v8:4532
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, wingo@igalia.com

Review URL: https://codereview.chromium.org/1416753009

Cr-Commit-Position: refs/heads/master@{#31802}

Revert of [es6] Implement destructuring binding in try/catch (patchset #3 id:40001 of https://codereview.chromium.org/1417483014/ )

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}

It was shipped in M46 without incident.

Review URL: https://codereview.chromium.org/1411723007

Cr-Commit-Position: refs/heads/master@{#31636}

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}

This reverts commit 280a6f8e.

Reland of https://codereview.chromium.org/1380593002/

BUG=chromium:535160
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel;

Review URL: https://codereview.chromium.org/1390473003

Cr-Commit-Position: refs/heads/master@{#31094}

Revert of [swarming] Isolate v8 testing. (patchset #8 id:140001 of https://codereview.chromium.org/1380593002/ )

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}