Similar to DELETE, the IN builtin is just a thin wrapper for %HasElement
and %HasProperty anyway, and cannot be optimized, plus it had a weird
special fast case (which also involved at least one LOAD_IC plus some
intrinsic magic).

R=yangguo@chromium.org,jarin@chromium.org

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

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

Revert of Debugger: use a Map to cache mirrors. (patchset #1 id:1 of https://codereview.chromium.org/1287243002/ )

Reason for revert:
Several nosnap and custom snapshot failures.

Original issue's description:
> Debugger: use a Map to cache mirrors.
>
> This makes mirror cache lookup O(1) instead of O(n).
> The downside is that the lookup via handle is O(n). This
> is fine because handles are only used in the JSON api,
> which is not used by Chrome and on death row.
>
> Committed: https://crrev.com/890b1dfca84d9dfecdcfc56517ef541076c6eb1d
> Cr-Commit-Position: refs/heads/master@{#30150}

TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

This CL us a pure refactoring that makes an empty compilation unit
including just "object.h" but not "object-inl.h" compile without
warnings or errors. This is needed to further reduce the header
dependency tangle.

R=bmeurer@chromium.org

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

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

Modifies the BytecodeArrayBuilder to create register operands which are
negative. This reduces the number of instructions to access registers
by the interpreter and allows us to use positive register operands to
access parameter values.

Adds a Register class to keep register usage typesafe and simplify the
convertion to bytecode operand values.

BUG=v8:4280
LOG=N

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

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

This makes mirror cache lookup O(1) instead of O(n).
The downside is that the lookup via handle is O(n). This
is fine because handles are only used in the JSON api,
which is not used by Chrome and on death row.

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

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

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

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

The DELETE builtin calls through to %DeleteProperty anyway, so we
can as well skip the builtin completely and always call into the
runtime directly.  Also add different entries depending on whether
calling code is in sloppy or strict/strong mode.

R=yangguo@chromium.org

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

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

R=yangguo@chromium.org

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

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

In strong mode, whenever either operand to an addition is a string, both
must be strings, so we can just use a simple string map check instead of
the STRING_ADD_LEFT / STRING_ADD_RIGHT machinery, which tries to do sloppy
and strict mode conversions before giving up.

R=jarin@chromium.org

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

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

Revert of Group lexical context variables for faster look up. (patchset #2 id:20001 of https://codereview.chromium.org/1281883002/ )

Reason for revert:
This performance hack is no longer necessary.

Original issue's description:
> Group lexical context variables for faster look up.
>
> Currently, looking up a lexical context variable requires looking up
> the variable name and then checking its mode. This can be a bottleneck
> in Runtime_DeclareGlobals, even when no lexical context variables are
> declared.
>
> R=rossberg@chromium.org
> BUG=crbug:517778
> LOG=N
>
> Committed: https://crrev.com/a45ed17bb6aca02e940f13bbf456d660cccc86ae
> Cr-Commit-Position: refs/heads/master@{#30075}

TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=crbug:517778

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

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

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

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

R=mstarzinger@chromium.org
BUG=

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

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

Rolling v8/third_party/android_tools to 5722f90e94d02a8dc17b6edb93ead6839d5afcee

TBR=machenbach@chromium.org

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

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

This patch puts --harmony-sloppy into staging. Now that let, lexically-scoped
functions and ES2015 sloppy mode const semantics have been split off into
separate flags, the change only enables classes in sloppy mode.

BUG=v8:3305
R=adamk
LOG=Y

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

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

This patch strengthens testing of classes by verifying that the binding
that they export externally follows block scoping, as opposed to var-style
scoping. The tests are based on existing tests for let and const.

R=adamk
LOG=N
BUG=v8:3305

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

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

The operations were available on ARM64 and x86-32 but were unused.

It has been conjectured that nontemporals can be used for rowhammer-like bitflips more easily than regular load/store operations. It is therefore desirable to avoid generating these instructions in the future.

R= titzer, jochen, jln, Mark Seaborn, ruiq

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

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

BUG=v8:4366
LOG=n

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

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

Also add a bigger warning to the header comment for the Maybe version.

R=jochen@chromium.org

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

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

R=jkummerow@chromium.org

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

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

Instead of using a sequence

  if (something == null && !IS_UNDETECTABLE(something))) { ... }

which will be true if something is either null or undefined, it is
way simpler and way more efficient to just write

  if (something === null || something === (void 0)) { ... }

instead, which allows the compiler(s) to generate pretty decent code
without any need to resort to type feedback from a CompareNil IC.

R=yangguo@chromium.org

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

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

We don't need it, as we can grab it from the shared function info.
Having it triggers an assertion if we define classes in native JS.

R=bmeurer@chromium.org, rossberg@chromium.org

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

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

TBR=bmeurer@chromium.org

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

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

Support for undetectable strings was officially dropped in
https://codereview.chromium.org/916753002, but the compilers
weren't fixed properly.

R=yangguo@chromium.org

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

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

R=yangguo@chromium.org

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

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

R=yangguo@chromium.org

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

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

Don't use IS_NULL_OR_UNDEFINED() for CHECK_OBJECT_COERCIBLE() because it
will also return true for undetectable objects, but use IS_NULL() and
IS_UNDEFINED() directly, which will only return true for null or
undefined (which matches the semantics of the abstract operation
CheckObjectCoercible).

R=yangguo@chromium.org

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

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

R=danno@chromium.org

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

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

R=bmeurer@chromium.org

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

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

R=bmeurer@chromium.org

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

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

This tries to remove includes of "-inl.h" headers from normal ".h"
headers, thereby reducing the chance of any cyclic dependencies and
decreasing the average size of our compilation units.

Note that this change still leaves 7 violations of that rule in the
code. However there now is the "tools/check-inline-includes.sh" tool
detecting such violations.

R=bmeurer@chromium.org

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

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

R=bmeurer@chromium.org
BUG=chromium:517594
LOG=N

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

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

Clang says: warning: 'const' type qualifier on return type has no effect
[-Wignored-qualifiers]

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

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

In an initial attempt to implement sloppy mode lexical bindings,
functions were made lexically scoped in sloppy mode. However, the
ES2015 spec says that they need an additional hoisted var binding,
and further, it's not clear when we'll implement that behavior
or whether it's web-compatible.

This patch splits off function block scoping into a new, separate
flag called --harmony_sloppy_function. This change will enable the
possibility of testing and shipping this feature separately from
other block scoping-related features which don't have the same risks.

BUG=v8:4285
R=adamk
LOG=N

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

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

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

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

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

In ES6, direct eval() in sloppy mode uses the enclosing function-level
("var") scope for var-style bindings and a new lexical scope for lexical
bindings like let and class. This patch implements that feature by making
lexical bindings that are directly within an EVAL_SCOPE be on the local
scope rather than the enclosing one.

BUG=v8:4288
LOG=Y
R=adamk

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

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

This way we can greatly simplify the different variants of ToObject in
our codebase and make them more uniform and robust.  Adding a new
primitive doesn't require finding and changing all those places again,
but it is sufficient to setup the constructor function index when
allocating the map.

We use the inobject properties field of Map, which is invalid primitive
maps anyway.

R=jkummerow@chromium.org

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

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

R=adamk
BUG=chromium:135066
LOG=N

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

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

R=littledan@chromium.org, adamk@chromium.org
BUG=v8:3575
LOG=Y

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

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

The previous approach to this (in 1b1de2d2) did not work well with
bots that intentionally run no tests. But I think this warning message
is still useful for developers.

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

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

Reland: [turbofan] Various fixes to allow unboxed doubles as arguments in registers and on the stack.

OCL: https://codereview.chromium.org/1263033004/

R=mstarzinger@chromium.org
BUG=

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

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