This change add a new bytecode for operator new and implements it using
the Construct() builtin.

BUG=v8:4280
LOG=N

Committed: https://crrev.com/8e4f9963d53913eab7fbd2f61a5733d8dc2169e7
Cr-Commit-Position: refs/heads/master@{#31293}

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

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

Revert of [Interpreter] Support for operator new. (patchset #17 id:290001 of https://codereview.chromium.org/1402943002/ )

Reason for revert:
[Sheriff] Breaks arm64 debug:
http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/4595

Original issue's description:
> [Interpreter] Support for operator new.
>
> This change add a new bytecode for operator new and implements it using
> the Construct() builtin.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/8e4f9963d53913eab7fbd2f61a5733d8dc2169e7
> Cr-Commit-Position: refs/heads/master@{#31293}

TBR=rmcilroy@chromium.org,bmeurer@chromium.org,oth@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280

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

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

This change add a new bytecode for operator new and implements it using
the Construct() builtin.

BUG=v8:4280
LOG=N

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

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

- Reflect.deleteProperty
- Reflect.get
- Reflect.has
- Reflect.isExtensible

Reflect.get doesn't support the receiver argument yet, and
some of the others don't support proxies yet.

R=rossberg
BUG=v8:3931
LOG=n

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

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

Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

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

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

Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ )

Reason for revert:
Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)

Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>

TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280

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

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

Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
Cr-Commit-Position: refs/heads/master@{#31064}

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

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

Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #6 id:180001 of https://codereview.chromium.org/1362383002/ )

Reason for revert:
Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this).

Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
> Cr-Commit-Position: refs/heads/master@{#31064}

TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280

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

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

Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

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

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

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}

There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4413, v8:4430
LOG=n

Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
Cr-Commit-Position: refs/heads/master@{#30900}

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

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

Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )

Reason for revert:
Failed on Fuzzer and MIPS bot.

Original issue's description:
> [es6] Introduce spec compliant IsConstructor.
>
> There was already a bit on the Map named "function with prototype",
> which basically meant that the Map was a map for a JSFunction that could
> be used as a constructor. Now this CL generalizes that bit to
> IsConstructor, which says that whatever (Heap)Object you are looking at
> can be used as a constructor (i.e. the bit is also set for bound
> functions that can be used as constructors and proxies that have a
> [[Construct]] internal method).
>
> This way we have a single chokepoint for IsConstructor checking, which
> allows us to get rid of the various ways in which we tried to guess
> whether something could be used as a constructor or not.
>
> Drive-by-fix: Renamed IsConstructor on FunctionKind to
> IsClassConstructor to resolve the weird name clash, and the
> IsClassConstructor name also matches the spec.
>
> R=jarin@chromium.org, rossberg@chromium.org
> BUG=v8:4430
> LOG=n
>
> Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
> Cr-Commit-Position: refs/heads/master@{#30900}

TBR=jarin@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4430

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

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

There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4430
LOG=n

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

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

Introduce new builtins Construct and ConstructFunction (in line
with the Call and CallFunction builtins that we already have) as
proper bottleneck for Construct and [[Construct]] on JSFunctions.
Use these builtins to support passing NewTarget from C++ to
JavaScript land.

Long-term we want the CallConstructStub to be used for
gathering feedback on entry to construction chain (i.e. the
initial new Foo), and use the Construct builtins to do the
actual work inside the construction chain (i.e. calling into
super and stuff).

MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.

R=jarin@chromium.org
BUG=v8:4430
LOG=n

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

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

No need to rely on the %_IsConstructCall magic here, we can just
implement the Symbol constructor in C++ altogether (it was just a
stupid wrapper around %CreateSymbol anyway).

R=mstarzinger@chromium.org

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

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

Implement the String constructor completely as native builtin,
avoiding the need to do gymnastics in JavaScript builtin to
properly detect the no argument case (which is different from
the undefined argument case) and also allowing to just
tailcall through to ToString or SymbolDescriptiveString for
the common case. Also the JavaScript builtin was misleading
since the case for construct call was unused, but could be
triggered in a wrong way once we support tail calls from
constructor functions.

This refactoring allows us to properly implement subclassing
for String builtins, once we have the correct initial_map on
derived classes (it's merely a matter of using NewTarget
instead of the target register now).

This introduces a new %SymbolDescriptiveString runtime
entry, which is also used by Symbol.toString() now.

R=mstarzinger@chromium.org

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

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

Adds support for JS calls to the interpreter. In order to support
calls from the interpreter, the PushArgsAndCall builtin is added
which pushes a sequence of arguments onto the stack and calls
builtin::Call.

Adds the Call bytecode.

MIPS port contributed by akos.palfi@imgtec.com in https://codereview.chromium.org/1334873002/

BUG=v8:4280
LOG=N

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

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

The new Call and CallFunction builtins supersede the current
CallFunctionStub (and CallIC magic) and will be the single bottleneck
for all calling, including the currently special Function.prototype.call
and Function.prototype.apply builtins, which had handwritten (and
not fully compliant) versions of CallFunctionStub, and also the
CallIC(s), which where also slightly different.

This also reduces the overhead for API function calls, which is still
unnecessary high, but let's do that step-by-step.

This also fixes a bunch of cases where the implicit ToObject for
sloppy receivers was done in the wrong context (in the caller
context instead of the callee context), which basically meant
that we allowed cross context access to %ObjectPrototype%.

MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.

R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
BUG=v8:4413
LOG=n

Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
Cr-Commit-Position: refs/heads/master@{#30627}

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

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

Revert of [builtins] Unify the various versions of [[Call]] with a Call builtin. (patchset #10 id:260001 of https://codereview.chromium.org/1311013008/ )

Reason for revert:
Breaks nosnap, needs investigation

Original issue's description:
> [builtins] Unify the various versions of [[Call]] with a Call builtin.
>
> The new Call and CallFunction builtins supersede the current
> CallFunctionStub (and CallIC magic) and will be the single bottleneck
> for all calling, including the currently special Function.prototype.call
> and Function.prototype.apply builtins, which had handwritten (and
> not fully compliant) versions of CallFunctionStub, and also the
> CallIC(s), which where also slightly different.
>
> This also reduces the overhead for API function calls, which is still
> unnecessary high, but let's do that step-by-step.
>
> This also fixes a bunch of cases where the implicit ToObject for
> sloppy receivers was done in the wrong context (in the caller
> context instead of the callee context), which basically meant
> that we allowed cross context access to %ObjectPrototype%.
>
> MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
>
> R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
> BUG=v8:4413
> LOG=n
>
> Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
> Cr-Commit-Position: refs/heads/master@{#30627}

TBR=rmcilroy@chromium.org,jarin@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4413

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

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

The new Call and CallFunction builtins supersede the current
CallFunctionStub (and CallIC magic) and will be the single bottleneck
for all calling, including the currently special Function.prototype.call
and Function.prototype.apply builtins, which had handwritten (and
not fully compliant) versions of CallFunctionStub, and also the
CallIC(s), which where also slightly different.

This also reduces the overhead for API function calls, which is still
unnecessary high, but let's do that step-by-step.

This also fixes a bunch of cases where the implicit ToObject for
sloppy receivers was done in the wrong context (in the caller
context instead of the callee context), which basically meant
that we allowed cross context access to %ObjectPrototype%.

MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.

R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
BUG=v8:4413
LOG=n

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

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

This way we don't need to expose JSReceiver::OrdinaryToPrimitive
as runtime function, and we don't need the separate JS trampoline.

This also adds tests for ToPrimitive on date objects, which are
special.

R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n

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

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

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

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

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

The previous hack with HInstanceOfKnownGlobal was not only slower,
but also very brittle and required a lot of weird hacks to support it. And
what's even more important it wasn't even correct (because a map check
on the lhs is never enough for instanceof).

The new implementation provides a sane runtime implementation
for InstanceOf plus a fast case in the InstanceOfStub, combined with
a proper specialization in the case of a known global in CrankShaft,
which does only the prototype chain walk (coupled with a code
dependency on the known global).

As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
implementation.

BUG=v8:4376
LOG=y

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

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

R=bmeurer@chromium.org

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

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

Add Object::StrictEquals to unify the implementation of strict equality
comparison in the runtime and the api (the api was already missing a
case for SIMD).  Now we (almost) have a single bottleneck for strict
equality, we just need to reduce the amount of unnecessary complexity
for the code stub.

R=yangguo@chromium.org

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

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

Revert of [runtime] Remove useless IN builtin. (patchset #2 id:20001 of https://codereview.chromium.org/1295433002/ )

Reason for revert:
Breaks win32 nosnap

Original issue's description:
> [runtime] Remove useless IN builtin.
>
> 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
>
> Committed: https://crrev.com/72d60a1e80e81e2e68ca402665e2acbc46c5e471
> Cr-Commit-Position: refs/heads/master@{#30154}

TBR=yangguo@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

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}

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}

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}

This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL).  For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject.  Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.

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

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

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

Adds interpreter entry and exit trampoline builtins. Also implements the
Return bytecode handler and fixes a few bugs in InterpreterAssembler
highlighted by running on other architectures.

MIPS and MIPS64 port contributed by Paul Lind (paul.lind@imgtec.com)

BUG=v8:4280
LOG=N

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

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

- split relocation info for debug break slots for
  - calls (with call arguments count as data)
  - construct calls
  - normal slots
- renamed DEBUG_BREAK into DEBUGGER_STATEMENT
- removed unused IC state for Debug stubs

R=ulan@chromium.org
BUG=v8:4269
LOG=N

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

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

R=bmeurer@chromium.org

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

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

Break point at calls are currently set via IC. To change this, we
need to set debug break slots instead. We also need to distinguish
those debug break slots as calls to support step-in.

To implement this, we add a data field to debug break reloc info to
indicate non-call debug breaks or in case of call debug breaks, the
number of arguments. We can later use this to find the callee on the
evaluation stack in Debug::PrepareStep.

BUG=v8:4269
R=ulan@chromium.org
LOG=N

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

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

BUG=v8:3147,v8:4269
LOG=N

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

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

Revert "Revert relanded strong property access CL"

Regression issues should be solved. Initial patchset is the original, subsequent patchsets are the fixing modifications.

This reverts commit 4ac7be56.

BUG=v8:3956
LOG=N

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

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

This makes new.target work in [[Call]] and [[Construct]] of ordinary
functions.

We achieve this by introducing a new construct stub for functions that
uses the new.target variable. The construct stub pushes the original
constructor just above the receiver in the construct frame.

BUG=v8:3887
LOG=N
R=adamk@chromium.org, dslomov@chromium.org

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

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

Reason:
Regressions in various benchmarks.

Revert "Revert of Revert of [strong] Implement strong mode restrictions on property access (patchset #1 id:1 of https://codereview.chromium.org/1189153002/)"

This reverts commit 41405c04.

Revert "X87: Revert of Revert of [strong] Implement strong mode restrictions on property access."

This reverts commit 48de5f4d.

Revert "Fix overlapping KeyedLoadIC bitfield."

This reverts commit 4e6c956a.

Revert "MIPS64: Fix 'Revert of Revert of [strong] Implement strong mode restrictions on property access'."

This reverts commit 74f97b0d.

BUG=

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

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

Revert of Revert of [strong] Implement strong mode restrictions on property access (patchset #1 id:1 of https://codereview.chromium.org/1189153002/)

Reason for revert:
Issue was ultimately caused/fixed by https://codereview.chromium.org/1194673002/

Original issue's description:
> Revert of [strong] Implement strong mode restrictions on property access (patchset #23 id:460001 of https://codereview.chromium.org/1168093002/)
>
> Reason for revert:
> Speculative revert, maybe breaks GC-stress
>
> http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/808
>
> Original issue's description:
> > [strong] Implement strong mode restrictions on property access
> >
> > Implements the strong mode proposal's restrictions on property access.
> >
> > To be fully explored in a followup: proxies, interceptors, access checks, load from super
> >
> > BUG=v8:3956
> > LOG=N
> >
> > Committed: https://crrev.com/85dbfb9a389e7b21bd2a63862202ee97fc5d7982
> > Cr-Commit-Position: refs/heads/master@{#29109}
>
> TBR=rossberg@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:3956
>
> Committed: https://crrev.com/407657b706711fd5f8d417841e24b284886f3776
> Cr-Commit-Position: refs/heads/master@{#29115}

TBR=rossberg@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3956
LOG=N

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

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

Revert of [strong] Implement strong mode restrictions on property access (patchset #23 id:460001 of https://codereview.chromium.org/1168093002/)

Reason for revert:
Speculative revert, maybe breaks GC-stress

http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/808

Original issue's description:
> [strong] Implement strong mode restrictions on property access
>
> Implements the strong mode proposal's restrictions on property access.
>
> To be fully explored in a followup: proxies, interceptors, access checks, load from super
>
> BUG=v8:3956
> LOG=N
>
> Committed: https://crrev.com/85dbfb9a389e7b21bd2a63862202ee97fc5d7982
> Cr-Commit-Position: refs/heads/master@{#29109}

TBR=rossberg@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3956

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

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