Rolling v8/tools/clang to dc542e2b87607a399e0c107b78990aba11f5af48

TBR=machenbach@chromium.org

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

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

BUG=v8:3018
LOG=N

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

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

The Map and Set maps get overwritten when collection.js executes, so in
a nosnap build we have to wait until it runs before we grab the maps.
To facilitate that, store the functions in the native context as well.

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

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

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}

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}

Revert of [es6] implement default parameters via desugaring (patchset #19 id:380001 of https://codereview.chromium.org/1127063003/)

Reason for revert:
Broken on arm64

Original issue's description:
> [es6] implement default parameters via desugaring
>
> Stage 1 implementation:
>
> - Parameters can't be referenced before initialized (from left-to-right)
> - SingleNameBindings only, no support for BindingPatterns
>
> Known issues:
>
> - Incorrect scoping (parameter expressions may reference variables declared in function body)
> - Function arity is untouched
> - Hole-checking needs work
> - Rest parameters are broken when mixed with optional arguments
>
> BUG=v8:2160
> LOG=N
> R=arv@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/892c85485881f8be2f17bd83238980f858126576
> Cr-Commit-Position: refs/heads/master@{#28739}

TBR=rossberg@chromium.org,wingo@igalia.com,arv@chromium.org,dslomov@chromium.org,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2160

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

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

Stage 1 implementation:

- Parameters can't be referenced before initialized (from left-to-right)
- SingleNameBindings only, no support for BindingPatterns

Known issues:

- Incorrect scoping (parameter expressions may reference variables declared in function body)
- Function arity is untouched
- Hole-checking needs work
- Rest parameters are broken when mixed with optional arguments

BUG=v8:2160
LOG=N
R=arv@chromium.org, rossberg@chromium.org

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

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

Dictionary customization should be implemented in respective shape class.

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

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

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

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

Added /infra with chrome-infra specific files.
/infra/project-config/cr-buildbucket.cfg defines v8 buckets on cr-buildbucket.appspot.com

R=tandrii@chromium.org, machenbach@chromium.org, sergiyb@chromium.org
BUG=

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

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

Revert of [es6] Super call in arrows and eval (patchset #5 id:100001 of https://codereview.chromium.org/1146863007/)

Reason for revert:
Fails

http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/579/steps/Check/logs/super

Original issue's description:
> [es6] Super call in arrows and eval
>
> This splits the SuperReference AST node into SuperPropertyReference and
> SuperCallReference. The super call reference node consists of three
> unresolved vars to this, new.target and this_function. These gets
> declared when the right function is entered and if it is in use. The
> variables gets assigned in FullCodeGenerator::Generate.
>
> BUG=v8:3768
> LOG=N
> R=wingo@igalia.com, adamk@chromium.org
>
> Committed: https://crrev.com/673c0516ab96f24343bbb26e0afc2846b5a679df
> Cr-Commit-Position: refs/heads/master@{#28731}

TBR=wingo@igalia.com,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3768

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

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

Port e2e47f30

Original commit message:
In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a
simple runtime call to ForInFilter, which does everything and is even
cheaper (because FILTER_KEY used to call into the runtime anyway).
And ForInFilter returns either the name or undefined, which makes it
possible to remove the control flow construction from the AstGraphBuilder,
and thereby make both the initialization and the per-loop code of for-in
optimizable later (in typed lowering).

R=bmeurer@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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

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

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

This updates Dictionary classes hierarchy and introduces GlobalDictionary class but it is not used yet.

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

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

This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.

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

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

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

R=hpayer@chromium.org
BUG=

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

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

R=mstarzinger@chromium.org
BUG=v8:3996
LOG=y

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

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

Make sure that --print-ast works even when the class expression has no
name.

This also updates the printer to print the properties of the class
literal.

BUG=v8:4138
LOG=N
R=rossberg

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

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

R=hpayer@chromium.org
TEST=mjsunit/regress/regress-crbug-493779
BUG=chromium:493779
LOG=N

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

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

This is basically a port of the majority of optimizations that are
applied to for-in in full codegen. But it is not done during graph
building, but instead during typed lowering, which way less adhoc than
what the other compilers do.

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

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

Note that this essentially disables optimization of "with" as well.

R=hablich@chromium.org
BUG=chromium:491897,chromium:491018
LOG=N

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

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

Implements the strong mode proposal's restrictions on the behaviour of the
delete operator for strong objects.

Setting the strong bit is still wip, so this change will only affect those
objects that have the bit correctly set. The tests reflect this, and will be
expanded as more objects can be marked as strong.

Attempt 2, last version did not work with API.

BUG=v8:3956
LOG=N

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

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

Revert of Re-enable on-heap typed array allocation (patchset #1 id:1 of https://codereview.chromium.org/1166433004/)

Reason for revert:
Win32 breakage

Original issue's description:
> Re-enable on-heap typed array allocation
>
> BUG=v8:3996
> R=mstarzinger@chromium.org
> LOG=y
>
> Committed: https://crrev.com/f91df1f25dec4f1982c40af6118da8b699777475
> Cr-Commit-Position: refs/heads/master@{#28722}

TBR=mstarzinger@chromium.org,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3996

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

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

BUG=v8:3996
R=mstarzinger@chromium.org
LOG=y

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

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

TEST=mjsunit/asm/double-lo
BUG=

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

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

port 3a1d7335 (r28683)

original commit message:

  This finishes up work begun by CL (https://codereview.chromium.org/546683003/) some months ago.

BUG=

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

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

port 388e791d (r28672).

original commit message:

   The list of inlined functions is used in exactly two places - for live
    edit and to prevent code flushing for inlined functions - and those are
    fine with SharedFunctionInfo and don't require a closure.

    This is one additional step towards inlining based on SharedFunctionInfo
    instead of JSFunction.

BUG=

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

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

port 5450fc07 (r18659)

original commit message:

    Also adapt code generation to pass the slot to the
    store/keyed-store ic. AST nodes ObjectLiteral, Assignment,
    ForEach, Call and CountOperation now include one or more
    feedback vector ic slot ids.

BUG=

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

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

port 44e98103 (r28644)

original commit message:

    When we enter a method that needs access to the [[HomeObject]]
    we allocate a local variable `.home_object` and assign it the
    value from the [[HomeObject]] private symbol. Something along
    the lines of:

      method() {
        var .home_object = %ThisFunction()[home_object_symbol];
        ...
      }

BUG=

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

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

port eca5b5d7 (r28622).

original commit message:

   * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
    * In the long run we should do all hidden properties this way and get rid of the
    hidden magic 0-length string with the zero hash code.  The advantages include
    less complexity and being able to do things from JS in a natural way.
    * Initially, the performance of weak set regressed, because it's a little harder
    to do the lookup in C++.  Instead of heroics in C++ to make things faster I
    moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
    * This also changes hash codes of Smis so that they are always Smis.

    Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.

    In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new

    In a similar vein we could give the magic zero hash code to the hash code
    symbol.  Then when we look up the hash code we would sometimes see the table
    with all the hidden properties.  This dual use of the field for either the hash
    code or the table with all hidden properties and the hash code is rather ugly,
    and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.

    One worry is that the benchmark results above are more monomorphic than real
    world code, so may be overstating the performance benefits of moving to JS.  I
    think this is part of a general issue we have with handling polymorphic code in
    JS and any solutions there will benefit this solution, which boils down to
    regular property access. Any improvement there will lift all boats.

BUG=

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

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

port 32de6778 (r29615)

original commit message:

    The reason is that this information will be needed to compute the number of
    vector ic slots done at numbering time.

BUG=

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

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

R=arv@chromium.org, mstarzinger@chromium.org
BUG=v8:4131
LOG=n

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

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

This introduces two new operators for loads of variables bound to
Variable::LOOKUP locations. Currently they all still lower to runtime
calls, but will allow optimization during typed lowering.

R=bmeurer@chromium.org

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

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

In contrast to CreateDataProperty, this will always call out to JS

BUG=475206
R=adamk@chromium.org,verwaest@chromium.org
LOG=y

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

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

In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a
simple runtime call to ForInFilter, which does everything and is even
cheaper (because FILTER_KEY used to call into the runtime anyway).
And ForInFilter returns either the name or undefined, which makes it
possible to remove the control flow construction from the AstGraphBuilder,
and thereby make both the initialization and the per-loop code of for-in
optimizable later (in typed lowering).

R=jarin@chromium.org

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

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

Fix another may be uninitialized compile failure on AIX
in src/heap/heap.cc

R=svenpanne@chromium.org, mbrandy@us.ibm.com

BUG=

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

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

Use __ARM_ARCH_6ZK__ instead of __ARM_ARCH_6KZ__. The architecture is
technically called ARMv6KZ, but GCC has always called it 6ZK.

Clang defines __ARM_ARCH_6K__ for this target, and is unaffected.

BUG=v8:3978
LOG=N

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

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

Rolling v8/tools/clang to ed19e3a88ba8dccc757b6f2e76d06c5d1355cfa3

TBR=machenbach@chromium.org

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

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

R=hpayer@chromium.org, szager@chromium.org
TBR=hpayer@chromium.org
BUG=

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

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

Rolling v8/tools/clang to 4a73eedb03ade4ca209eadcf768737ca01bf7b4a

TBR=machenbach@chromium.org

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

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