This is a rework of the instanceof operator to support ES6 semantics
(as per section 12.10.4 of the spec:
https://tc39.github.io/ecma262/#sec-instanceofoperator).

It's behind flag --harmony-instanceof for now, which is turned on for staging.

BUG=v8:4447
LOG=N

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

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

Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.

Also eliminates a couple of spurious dependencies.

R=mstarzinger@chromium.org
BUG=

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

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

R=jkummerow@chromium.org
BUG=v8:4450
LOG=N

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

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

This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.

R=bmeurer@chromium.org

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

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

The asm.js spec decides the type of numeric literals in several places
based on if they contain a ".".
http://asmjs.org/spec/latest/

Adding methods so that AST Literals can be checked for containg a dot.

Adding a cctest that this information is available.

LOG=N
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-parsing
R=rossberg@chromium.org,titzer@chromium.org

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

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

Before this we had 3 super related lexical bindings that got injected
into method bodies: .home_object, .this_function,  and new.target.
With this change we get rid of the .home_object one in favor of using
.this_function[home_object_symbol] which allows some simplifications
throughout the code base.

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

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

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

When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.

R=ulan@chromium.org
BUG=

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

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

R=jochen@chromium.org

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

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

This avoids both a mysterious boolean argument ("insert") and lets
non-mutating lookups skip passing an allocator (in one such case,
we were passing a scary-looking ZoneAllocationPolicy(NULL)!).

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

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

These comparisons are only meant to be done by AstValueFactory itself (in
its string_table_ operations), so make the Compare() function a private
member of AstValueFactory.

All other clients of AstRawStrings should compare them by pointer value.
There were only two clients which failed to abide by this rule, one
recently-added (in ModuleDescriptor) and the other in Literal::Match
(in ast.cc, added in https://code.google.com/p/v8/source/detail?r=24396).

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

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

FINAL implies OVERRIDE, which in turn implies virtual, so there's no need to use
more than one of these. The Google C++ style guide even requires this, see
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance.

While we're here, port r24662 to x87.

The net result is that v8 compiles again with a current clang.

BUG=v8:3753
LOG=y

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

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

This allows serializing public symbols that are embedded in code.

BUG=v8:3689
LOG=N
R=rossberg@chromium.org

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

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

The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.

The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.

This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.

BUG=
R=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25179}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts r25155.

Reason: breaks webkit unit tests.

BUG=
TBR=marja@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25159}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25159 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.

The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.

This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.

R=rossberg@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#25155}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25155 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit 94a08565 for
breaking layout tests.

TBR=marja@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25121}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25121 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

1) In ParseLazy, we're already using the heap, so we can also tell
AstValueFactory to internalize immediately. This is more efficient.

2) No need to collect the values in values_ and strings_ if they're already
internalized.

3) No need to collect AstValues which are strings in values_ since they don't
need to be internalized (the underlying strings will be internalized
separately).

BUG=429168
LOG=N
R=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25109}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25019}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25019 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

They were not, so we were creating several instances of them, one for each time
they occurred in the source code.

It's not known to have caused efficiency problems though, so this is a sanity
fix more than an efficiency fix.

Note that numbers are still not unique.

BUG=
R=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#24873}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Again 50MB less peak memory usage in the bug mentioned below...

BUG=417697
LOG=y
R=dcarney@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24396 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=dcarney@chromium.org, marja@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23840 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Less useless creativity is best creativity!

R=svenpanne@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23579 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This way we don't clash with the ASSERT* macros
defined by GoogleTest, and we are one step closer
to being able to replace our homegrown base/ with
base/ from Chrome.

R=jochen@chromium.org, svenpanne@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a reincarnation of r21841.

The previous try was https://codereview.chromium.org/314603004/ but it regressed
JSBench and morejs.

BUG=
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Plus the fixes on top.

Reason: regresses benchmarks (JSBench) and perf (morejs).

TBR=rossberg@chromium.org
BUG=385404
LOG=N

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21882 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=mstarzinger@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21845 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is needed so that we can run Parser on a non-main thread (independent
of the Isolate and the V8 heap).

BUG=
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21841 ce2b1a6d-e550-0410-aec6-3dcde31c8c00