Original issue's description:
> [es6] Better support for built-ins subclassing.
>
> Create proper initial map for original constructor (new.target) instead of doing prototype
> transition on the base constructor's initial map. This approach fixes in-object slack tracking
> for subclass instances.
> This CL also fixes subclassing from String.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/cd5f48302a502154a0106d12e3066bd563c6340c
> Cr-Commit-Position: refs/heads/master@{#31680}
It also fixes typed array map smashing done during typed array initialization.
BUG=v8:3101, v8:3330, v8:4419
LOG=Y
Review URL: https://codereview.chromium.org/1413033006
Cr-Commit-Position: refs/heads/master@{#31701}
Create proper initial map for original constructor (new.target) instead of doing prototype transition on the base constructor's initial map. This approach fixes in-object slack tracking for subclass instances.
This CL also fixes subclassing from String.
BUG=v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1427483002
Cr-Commit-Position: refs/heads/master@{#31680}
This is in preparation of implementing Reflect.set.
Besides making SetSuperProperty and others return Maybe<bool>, this CL
also fixes some parts of my previous refactoring of SetProperty and
others: It doesn't make sense to take both a language_mode and a
should_throw argument. A strict language_mode should imply
THROW_ON_ERROR.
R=rossberg, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1431443003
Cr-Commit-Position: refs/heads/master@{#31678}
We have plans to create more ICs, and we are out of bits to represent the Kind
in the flags field of the code object. The InlineCacheState can lose a bit
because it no longer needs the DEFAULT state. That state existed as a way to
detect errors where code incorrectly looked at a vector IC stub's
InlineCacheState instead of correctly determining said state from a glance at
the vector. This really isn't a danger anymore.
So, with the horse trading, we could now represent up to 32 code kinds.
BUG=
Review URL: https://codereview.chromium.org/1427803003
Cr-Commit-Position: refs/heads/master@{#31666}
Drive-by-fix: Move IC::GetRootConstructor to Map::GetConstructorFunction,
so we can use that in the ICs, Crankshaft and Turbofan.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1416493007
Cr-Commit-Position: refs/heads/master@{#31577}
This is in preparation of implementing Reflect.set.
R=rossberg
BUG=
Review URL: https://codereview.chromium.org/1394983005
Cr-Commit-Position: refs/heads/master@{#31501}
Also clean up the access check, which was doing too much.
This is in preparation of implementing Reflect.getPrototypeOf.
BUG=
Review URL: https://codereview.chromium.org/1402973002
Cr-Commit-Position: refs/heads/master@{#31434}
Separately collect element keys from property keys to avoid slow
corner-cases. Partly deal with keys generated by Proxies.
BUG=chromium:536790
LOG=N
Review URL: https://codereview.chromium.org/1397063002
Cr-Commit-Position: refs/heads/master@{#31378}
Native context specialization now lowers monomorphic and
polymorphic accesses to data and constant data properties on
object and/or prototype chain. We don't deal with accessors
yet, and we also completely ignore proxies (which is compatible
with what Crankshaft does).
The code is more or less the straightforward implementation. We
will need to refactor that and extract common patterns once the
remaining bits for full load/store support is in.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
Cr-Commit-Position: refs/heads/master@{#31340}
Review URL: https://codereview.chromium.org/1396333010
Cr-Commit-Position: refs/heads/master@{#31352}
Adds basic support for iterating interpreter stack frames for GC. Currently
InterpreterStackFrames are treated just like JavaScriptStackFrames since the
JavaScriptFrame::IterateExpressions() will correctly iterate over all the
local / temp interpeter Registers, and will iterate over the
interpreter_entry_trampoline pc address. There is no need to explicitly
iterate over the BytecodeArray object since that is held in a machine
register in the bytecode handler which is marked as kMachTaggedAny by
TurboFan, and so will get iterated appropriately when iterating the
bytecode handler stub's stack frame.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1407513003
Cr-Commit-Position: refs/heads/master@{#31342}
Reason for revert:
Waterfall redness.
Original issue's description:
> [turbofan] Initial support for monomorphic/polymorphic property loads.
>
> Native context specialization now lowers monomorphic and
> polymorphic accesses to data and constant data properties on
> object and/or prototype chain. We don't deal with accessors
> yet, and we also completely ignore proxies (which is compatible
> with what Crankshaft does).
>
> The code is more or less the straightforward implementation. We
> will need to refactor that and extract common patterns once the
> remaining bits for full load/store support is in.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
> Cr-Commit-Position: refs/heads/master@{#31340}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review URL: https://codereview.chromium.org/1408123002
Cr-Commit-Position: refs/heads/master@{#31341}
Native context specialization now lowers monomorphic and
polymorphic accesses to data and constant data properties on
object and/or prototype chain. We don't deal with accessors
yet, and we also completely ignore proxies (which is compatible
with what Crankshaft does).
The code is more or less the straightforward implementation. We
will need to refactor that and extract common patterns once the
remaining bits for full load/store support is in.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1396333010
Cr-Commit-Position: refs/heads/master@{#31340}
This makes it explicit when the --ignition-filter pattern should be
applied to the script name instead of the function name by using a
proper "s:{name}" pattern. It also hardcodes it to be a prefix match
instead of an exact match, because that is all we need for test262.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1389353002
Cr-Commit-Position: refs/heads/master@{#31153}
Thus TypeFeedbackMetadata can now be shared between different native contexts.
Review URL: https://codereview.chromium.org/1384673002
Cr-Commit-Position: refs/heads/master@{#31143}
Adds support for compiling top level code to bytecode to be run in the
interpreter.
Also moves PassesFilter to String:: so that it can be used to filter top
level script names as well as functions (used in
https://codereview.chromium.org/1379093002/)
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1372293005
Cr-Commit-Position: refs/heads/master@{#31142}
Symbols marked as "well-known" now return an undefined value when loaded with a failed access check, instead of throwing.
Currently, only @@isConcatSpreadable is marked as well-known, until the correct behaviour is properly specified.
BUG=v8:4289, 507553
LOG=N
R=adamk@chromium.org, jochen@chromium.org, verwaest@chromium.org
Review URL: https://codereview.chromium.org/1230793002
Cr-Commit-Position: refs/heads/master@{#31131}
Now there are two functions, one corresponding to the spec's
[[PreventExtensions]] and one corresponding to Object.preventExtensions.
They differ in what they return.
This CL is in preparation of implementing Reflect.preventExtensions.
R=rossberg
BUG=
Review URL: https://codereview.chromium.org/1377103005
Cr-Commit-Position: refs/heads/master@{#31096}
We need to do other things with this bindings object, like store a feedback vector. Therefore, it's a good time to wrap it up in a helper class.
BUG=
Review URL: https://codereview.chromium.org/1369293003
Cr-Commit-Position: refs/heads/master@{#31044}
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 LiteralsArray will soon hold a type feedback vector. Code treats it as an
ordinary fixed array, and needs to stop that.
BUG=
Review URL: https://codereview.chromium.org/1374723002
Cr-Commit-Position: refs/heads/master@{#31000}
This adds ES6 compliant Object::ToInteger, Object::ToInt32,
Object::ToUint32 and Object::ToLength, and replaces the old
Execution wrappers of those abstract operations (which were
not using the correct ToPrimitive).
This also introduces proper %ToInteger and %ToLength runtime
entries, with a fast path %_ToInteger supported in fullcodegen
and Crankshaft (for now). Internal JavaScript code should use
TO_INTEGER and TO_LENGTH respectively.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1378533002
Cr-Commit-Position: refs/heads/master@{#30993}
The comparison operators and ToBoolean are implemented by calling into
the runtime. There are new runtime methods are prefixed with Interpreter
to make use case clear.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1369123002
Cr-Commit-Position: refs/heads/master@{#30983}
Replacing it with SMI_ACCESSORS.
This change makes accesses to Smi fields in objects more regular (the
accessors now always consume/return an int rather than a Smi*), which
avoids a bunch of manual Smi::FromInt() and Smi::value() conversions,
and is a step on the way towards being able to generate objects-inl.h.
Review URL: https://codereview.chromium.org/1371893002
Cr-Commit-Position: refs/heads/master@{#30975}
Reason for revert:
Reverting, because of broken GC stress bots.
@cbruni: Sorry for the revert. I'm not entirely sure it's actually your CL; but policy is to revert speculatively if we can't determine an exact cause.
Original issue's description:
> JSObject::GetEnumProperty cleanup
>
> BUG=
>
> Committed: https://crrev.com/a00d47c802f93cf9835eafce4c9da2dd10b44f6a
> Cr-Commit-Position: refs/heads/master@{#30946}
TBR=jkummerow@chromium.org,cbruni@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1371673004
Cr-Commit-Position: refs/heads/master@{#30950}
The actual Function.prototype.toMethod was removed some time already,
but there were some stuff (esp. %ToMethod) left in the tree, including
tests for %ToMethod. This code (and esp. the tests) cause trouble in
the process of moving bound functions away from JSFunction; so since
the code is unused anyway, we can as well remove it.
The original removal of Function.prototype.toMethod was in February
2015 in 68e4897586.
R=jarin@chromium.org
BUG=v8:3330
LOG=n
Review URL: https://codereview.chromium.org/1366063002
Cr-Commit-Position: refs/heads/master@{#30925}
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}
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}
Whenever a generalization is computed, the inputs must be checked for being cleared, and if they are, the generalization must be Type::Any.
Hopefully this fixes Chromium issue 527994 as well.
BUG=v8:4325,chromium:527994
LOG=n
Review URL: https://codereview.chromium.org/1361103002
Cr-Commit-Position: refs/heads/master@{#30887}
This CL also renames wrongly named test for v8:4173.
BUG=v8:4121
LOG=Y
Review URL: https://codereview.chromium.org/1353363002
Cr-Commit-Position: refs/heads/master@{#30879}
We don't need Object::IsSpecFunction anymore, since it only checks for
JSFunction and JSFunctionProxy, but what you actually want to check for
(in case of accessors) is whether the target has a [[Call]] internal
method, which is exactly what Object::IsCallable does.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=rossberg@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1358403002
Cr-Commit-Position: refs/heads/master@{#30875}
mdb_v8, a post-mortem debugging tool for Node.js, allows users to
inspect ScopeInfo structures in order to get more information about
closures.
Currently, it hardcodes the metadata it uses to find this information.
This change allows it to get this metadata from the node binary itself,
and thus to adapt to future changes made to the layout of the ScopeInfo
data structure.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1350843003
Cr-Commit-Position: refs/heads/master@{#30843}
This removes the weird COMPARE and COMPARE_STRONG JavaScript builtins
and replaces them with a proper C++ implementation in Object::Compare
and appropriate wrappers Object::LessThan, Object::GreaterThan, and
friends that are intended to be used by a true/false returning CompareIC
in the future, as well as the interpreter. As a short-term solution we
provide %Compare and %Compare_Strong entry points for the current
CompareIC that return the appropriate integer values expected by
fullcodegen currently.
Now the Abstract Relational Comparison is also using the correct
ToPrimitive implementation, which properly supports @@toPrimitive.
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1350113002
Cr-Commit-Position: refs/heads/master@{#30816}
The core bottleneck lies in N-square cost of array union. Depending on the size
of the arrays involved it makes sense to rely on a hash-set/table for the lookup.
LOG=N
BUG=v8:2904
Review URL: https://codereview.chromium.org/1316213008
Cr-Commit-Position: refs/heads/master@{#30797}
Move the implementation of the Abstract Equality Comparison to the
runtime and thereby remove the EQUALS dispatcher builtin. Also remove
the various runtime entry points that were only used to support the
EQUALS builtin.
Now the Abstract Equality Comparison is also using the correct
ToPrimitive implementation, which properly supports @@toPrimitive.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1337993005
Cr-Commit-Position: refs/heads/master@{#30747}
These builtins present an optimization for the general addition case,
where one side is already known to be a string. Unfortunately this
optimization is wrong in the presence of @@toPrimitive (there are some
ideas how to implement a similar optimization using the prototype
backpointer mechanism that jkummerow@ introduced earlier). So this
also removes the broken %_IsStringWrapperSafeForDefaultValueOf, which is
the key part of the optimization mentioned above.
R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1336273002
Cr-Commit-Position: refs/heads/master@{#30707}
Replace the ADD, SUB, etc. builtins with proper runtime implementations,
and expose them as runtime calls that can be used by the code stubs and
the interpreter (for now).
Also remove all the support runtime functions for ADD, SUB and friends,
namely %NumberAdd, %NumberSub, and so on.
R=mstarzinger@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
Review URL: https://codereview.chromium.org/1333843002
Cr-Commit-Position: refs/heads/master@{#30680}
This fixes the Runtime_DeclareGlobals performance regression caused by a huge number of global var declarations mentioned in chromium:517778.
BUG=chromium:517778
LOG=N
Review URL: https://codereview.chromium.org/1335633002
Cr-Commit-Position: refs/heads/master@{#30679}
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}
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}
Reason for revert:
[Sheriff] Changes several layout test expectations. Please fix upstream first if intended. E.g.:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/1729
Several lines change from PASS to FAIL.
Original issue's description:
> [es5] Class of object is "Function" if object has [[Call]].
>
> The concept of class was mostly removed from ES6, but we still use the
> class of objects to distinguish object kinds in our builtins. So update
> this to be in sync with IsCallable (thereby getting rid of the previous
> instance type based tests for callable things completely).
>
> R=jarin@chromium.org, jkummerow@chromium.org
>
> Committed: https://crrev.com/af778389947f1b01fb036756ea3cb8ed8ab98452
> Cr-Commit-Position: refs/heads/master@{#30566}
TBR=jarin@chromium.org,jkummerow@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1306303005
Cr-Commit-Position: refs/heads/master@{#30568}
The concept of class was mostly removed from ES6, but we still use the
class of objects to distinguish object kinds in our builtins. So update
this to be in sync with IsCallable (thereby getting rid of the previous
instance type based tests for callable things completely).
R=jarin@chromium.org, jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1307943013
Cr-Commit-Position: refs/heads/master@{#30566}
Use a single JSIteratorResult type for all implementation provided
iterator results (i.e. the String, Array and collection iterators,
and also for generators). This removes one source of unnecessary
polymorphism in for-of loops. It is accomplished by a new intrinsic
%_CreateIterResultObject() that should be used to create iterator
result objects from JavaScript builtins (there's a matching factory
method for C++ code).
Also restructure the %StringIteratorPrototype%.next() and
%ArrayIteratorPrototype%.next() functions to be a bit more friendly
to optimizing compilers.
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/1302173007
Cr-Commit-Position: refs/heads/master@{#30557}
This turns the has_instance_call_handler bit on Map into an is_callable
bit, that matches the spec definition of IsCallable (i.e. instances have
[[Call]] internal methods).
Also fix the typeof operator to properly say "function" for everything
that is callable.
Also remove the (unused) premature %_GetPrototype optimization from
Crankshaft, which just complicated the Map bit swap.
R=mstarzinger@chromium.org, rossberg@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
Review URL: https://codereview.chromium.org/1316933002
Cr-Commit-Position: refs/heads/master@{#30552}
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}
This is the first step towards a spec compliant ToPrimitive
implementation (and therefore spec compliant ToNumber, ToString,
ToName, and friends). It adds support for the @@toPrimitive
symbol that was introduced with ES2015, and also adds the new
Symbol.prototype[@@toPrimitive] and Date.prototype[@@toPrimitive]
initial properties.
There are now runtime functions for %ToPrimitive, %ToNumber and
%ToString, which do the right thing and should be used as fallbacks
instead of the hairy runtime.js implementations. I will do the
same for the other conversion operations mentioned by the spec in
follow up CLs. Once everything is in place we can look into
optimizing things further, so that we don't always call into the
runtime.
Also fixed Date.prototype.toJSON to be spec compliant.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=y
Review URL: https://codereview.chromium.org/1306303003
Cr-Commit-Position: refs/heads/master@{#30434}
Adds a (currently unused) constant_pool() field to BytecodeArray objects.
This field points to a FixedArray object which will be used to hold constants.
The BytecodeArray is now a mixed values object type, with the
kConstantPoolOffset object holding a tagged pointer, but the remainder of the
object holding raw bytes (which could look like tagged pointers but are not).
Modify the BytecodeArray GC visitors to deal with this and test that the
field is migrated properly when evacuated.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1314953004
Cr-Commit-Position: refs/heads/master@{#30404}
Adds support for parameters to the BytecodeArrayBuilder and BytecodeGenerator.
Parameters are accessed as negative interpreter registers.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1303403004
Cr-Commit-Position: refs/heads/master@{#30403}
The PLACEHOLDER code kind is used when compiling a code object that has
direct calls to other code objects, but those other code objects do not
yet exist because they have not yet been compiled. It serves as a
placeholder to break the cycle, e.g. in WASM.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1308393003
Cr-Commit-Position: refs/heads/master@{#30348}
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}
Adds Uint32x4, Uint16x8, and Uint8x16 types.
Adds all functions in the current spec, except for loads and stores.
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1294513004
Cr-Commit-Position: refs/heads/master@{#30322}
This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,
let x = 1;
function f(g = () => x) {
var y
eval("var x = 2")
return g() + x // f() = 3
}
we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:
- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.
- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).
- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.
- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.
- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.
- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.
- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.
- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.
- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.
- While at it, refactor and unify some respective code in the debugger.
Sorry, this CL is large. I could try to split it up, but everything is rather entangled.
@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N
Review URL: https://codereview.chromium.org/1292753007
Cr-Commit-Position: refs/heads/master@{#30295}
We can use the script type to determine that instead. Script of type
TYPE_NATIVE are considered builtins, TYPE_NORMAL are not. The only exception
to this rule is the empty function, for which the script is TYPE_NATIVE
(observable by the debugger), but should be stringified to "function () {}"
instead of "function () { [native code] }". For this, I introduce a
hide_source flag on the script object.
We also use IsBuiltin and IsSubjectToDebugging interchangeably. For debugger,
we now use the latter, hiding the detail that only non-builtins are debuggable.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1292283004
Cr-Commit-Position: refs/heads/master@{#30285}
This make inclusion of unicode-inl.h in object.h absolete. Now most
compilation units don't require that header. It also breaks a cycle
within declarations of the scanner.h header.
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 3 violations of that rule in the
code, checked with the "tools/check-inline-includes.sh" tool.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1287893006
Cr-Commit-Position: refs/heads/master@{#30268}
