It didn't support subclassing case at all and in non-subclassing case the runtime
allocation didn't do the slack tracking step.
BUG=chromium:563339
LOG=Y
Review URL: https://codereview.chromium.org/1488023002
Cr-Commit-Position: refs/heads/master@{#32547}
Split out of PropertyAttributes, and used for all filtering purposes.
Also moved PropertyAttributes into the v8::internal:: namespace.
No change in behavior intended.
Review URL: https://codereview.chromium.org/1492653004
Cr-Commit-Position: refs/heads/master@{#32525}
CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there is a request to make CallConstructStub look analogous. Enter ConstructICStub.
BUG=
Review URL: https://codereview.chromium.org/1476413003
Cr-Commit-Position: refs/heads/master@{#32452}
Reason for revert:
Broken canary. Trying to find out root cause.
Original issue's description:
> Introduce instance type for transition arrays.
>
> The motivation is to allow specialized marking visitor for transition arrays and collect all transition array in a list for post-processing in ClearNonLiveReferences.
>
> BUG=chromium:554488
> LOG=NO
>
> Committed: https://crrev.com/026095a3c7932573e1810b8064ec3008ed696601
> Cr-Commit-Position: refs/heads/master@{#32396}
TBR=mlippautz@chromium.org,jkummerow@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:554488
Review URL: https://codereview.chromium.org/1483003002
Cr-Commit-Position: refs/heads/master@{#32404}
The motivation is to allow specialized marking visitor for transition arrays and collect all transition array in a list for post-processing in ClearNonLiveReferences.
BUG=chromium:554488
LOG=NO
Review URL: https://codereview.chromium.org/1480873003
Cr-Commit-Position: refs/heads/master@{#32396}
Both are integrated into JSReceiver::GetKeys().
For now, the implementation ignores Symbol/DONT_ENUM filtering.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1474083003
Cr-Commit-Position: refs/heads/master@{#32384}
This makes sure that proxy + Function/Array works
Makes sure that new.target can be a generator
Makes sure that if new.target is not a subclass, but does not have a prototype, that we'll get that same prototype back the next time we look at new.target.prototype.
BUG=v8:1543, v8:3330, v8:3931
LOG=n
Review URL: https://codereview.chromium.org/1484473002
Cr-Commit-Position: refs/heads/master@{#32382}
This replaces internal GetConstructorName with toStringTag, .constructor's name
and class_name. This entirely changes how the name is computed for use in
devtools.
BUG=chromium:529177
LOG=n
Review URL: https://codereview.chromium.org/1435273002
Cr-Commit-Position: refs/heads/master@{#32374}
ES6 section 12.2.8.1 states that flags for regular expression literals
must be checked during parsing and invalid flags are early errors. This
change adapts the Scanner and (Pre)Parser to act according to the spec.
This is also a prerequisite to unify the handling of literal creation
(for Objects, Arrays, Regexps, and at some point Classes).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1472323002
Cr-Commit-Position: refs/heads/master@{#32273}
This is the initial step towards refactoring the regexp literation
creation code to make it less obscure and more similar to the mechanism
we use to create array and object literals. There's now a new runtime
entry %CreateRegExpLiteral with the same interface as the entries for
array and object literals, except that we still pass the flags as
string.
Instead of embedding the hand written native to clone JSRegExp instances
we now have a FastCloneRegExpStub, which behaves similar to the other
FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already
had.
R=mlippautz@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/1475823003
Cr-Commit-Position: refs/heads/master@{#32255}
There's no point in collecting feedback for super constructor calls,
because in all (interesting) cases we can gather (better) feedback from
other sources (i.e. via inlining or via using a LOAD_IC to get to the
[[Prototype]] of the target). So CallConstructStub is now only used
for new Foo(...args) sites where we want to collect feedback in the
baseline compiler. The optimizing compilers, Reflect.construct and
super constructor calls use the Construct builtin directly, which allows
us to remove some weird code from the CallConstructStub (and opens the
possibility for more code sharing with the CallICStub, maybe even going
for a ConstructICStub).
Also remove the 100% redundant HCallNew instruction, which is just a
wrapper for the Construct builtin anyway (indirectly via the
CallConstructStub).
Drive-by-fix: Drop unused has_function_cache bit on Code objects.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4413, v8:4430
LOG=n
Review URL: https://codereview.chromium.org/1469793002
Cr-Commit-Position: refs/heads/master@{#32172}
This simplifies the layout of dependent code array and optimizes it for sparse dependency groups.
BUG=chromium:554488
LOG=NO
Review URL: https://codereview.chromium.org/1435313002
Cr-Commit-Position: refs/heads/master@{#32170}
Introduce a JSCreateArray operator that represents the Array
constructor, and lower call and construct calls to the Array
constructor to JSCreateArray. Currently we don't yet replace
that with an inline allocation, but always use the specialized
stubs for the Array constructor.
This saves a lot of unnecessary deopts and elements transitions
because now we can actually consume the allocation site feedback
for the transitions.
R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1466643002
Cr-Commit-Position: refs/heads/master@{#32145}
Following logic is using for getting function name in JSFunction::GetDebugName:
1. if function has displayName and its type is string then use it
2. if function has defined property Function.name as value and its type string then use it
3. otherwise use SharedFunctionInfo::DebugName as functionName.
JSFunction::GetDebugName is exposed in V8 API and in FunctionMirror interface.
BUG=chromium:17356
R=yangguo@chromium.org,mstarzinger@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1449473005
Cr-Commit-Position: refs/heads/master@{#32124}
Lower access to byteOffset and byteLength getters on JSArrayBufferViews
and to length on JSTypedArrays. This requires a check to see whether the
backing JSArrayBuffer was neutered.
R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1453653003
Cr-Commit-Position: refs/heads/master@{#32070}
Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.
Landed on behalf of rmcilroy.
TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1449373002
Cr-Commit-Position: refs/heads/master@{#32049}
This CL introduces the following visitors:
1) RecordMigratedSlotVisitor which simplifies MarkCompactCollector::MigrateObject().
2) IteratePointersToFromSpaceVisitor which simplifies Heap::IteratePointersToFromSpace().
3) FindPointersToNewSpaceVisitor which simplifies StoreBuffer::IteratePointersToNewSpace().
These changes make the object's body descriptors the one and only place that knows how to traverse the object.
Review URL: https://codereview.chromium.org/1441453002
Cr-Commit-Position: refs/heads/master@{#31992}
1) Body descriptors moved to their own header files.
2) Missing body descriptors added.
3) Template versions of HeapObject::Iterate*() methods added.
4) Body descriptors support new kind of queries: IsValidSlot(offset) which can be used for invalid slots filtering.
This is a first step towards virtual and static visitors unification and support in-object properties in built-in (sub-)classes.
Review URL: https://codereview.chromium.org/1440243002
Cr-Commit-Position: refs/heads/master@{#31980}
The body descriptor supports different visiting policies: it could visit or skip
the code entry and it could visit or skip next function field.
BUG=v8:4531
LOG=Y
Review URL: https://codereview.chromium.org/1422773007
Cr-Commit-Position: refs/heads/master@{#31915}
Reason for revert: failed tests on a Windows build.
TBR=rossberg,cbruni,neis
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1426943007
Cr-Commit-Position: refs/heads/master@{#31907}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
This reverts commit 7f1fb29faa.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1418453008
Cr-Commit-Position: refs/heads/master@{#31876}
Reason for revert:
Causes GC-Stress failures.
Original issue's description:
> [heap] Separate out optimized code map processing.
>
> This separates the post-processing step for optimized code maps out of
> the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
> visit all candidates instead of gathering candidates during marking.
>
> Gathering candidates during marking no longer makes sense, now that the
> majority of SharedFunctionInfo objects will hold such an optimized code
> map. Also it reduces complexity of the implementation. Also conflating
> this mechanism with "code flushing" was confusing.
>
> This reverts commit b6644e8491.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/bb7a5eb2d89bae25f2b5ecb9515669f0ac73c111
> Cr-Commit-Position: refs/heads/master@{#31836}
TBR=ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1412063012
Cr-Commit-Position: refs/heads/master@{#31837}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
This reverts commit b6644e8491.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1421903012
Cr-Commit-Position: refs/heads/master@{#31836}
Reason for revert:
Breaks build: https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/3565
Original issue's description:
> [heap] Separate out optimized code map processing.
>
> This separates the post-processing step for optimized code maps out of
> the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
> visit all candidates instead of gathering candidates during marking.
>
> Gathering candidates during marking no longer makes sense, now that the
> majority of SharedFunctionInfo objects will hold such an optimized code
> map. Also it reduces complexity of the implementation. Also conflating
> this mechanism with "code flushing" was confusing.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/8ad6168d197dd167235c9d342ec7ce37b0daa88b
> Cr-Commit-Position: refs/heads/master@{#31830}
TBR=ulan@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1434503003
Cr-Commit-Position: refs/heads/master@{#31832}
Port ab84025977
Also:
- Fix big-endian compiler hints BYTE_OFFSET macro.
- Clean up PPC code access to compiler hints -- which required some new
SharedFunctionInfo fields to encapsulate kCompilerHintsSmiTagSize.
Original commit message:
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
R=bmeurer@chromium.org, cbruni@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1423713014
Cr-Commit-Position: refs/heads/master@{#31831}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1426953006
Cr-Commit-Position: refs/heads/master@{#31830}
This removes several methods from JSFunction that just delegate to
SharedFunctionInfo. These methods are especially dangerous when they
hide the fact that they potentially affect all function instances
deriving from the same underlying SharedFunctionInfo.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1417213005
Cr-Commit-Position: refs/heads/master@{#31792}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
Cr-Commit-Position: refs/heads/master@{#31786}
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31790}
Reason for revert:
failing build bot
Original issue's description:
> [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
>
> The current implementation of classes throws the TypeError at the wrong
> point, after activating a new context when directly calling a class
> constructor. According to the spec, the TypeError has to be thrown
> in the caller context.
>
> LOG=N
> BUG=v8:4428
>
> Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
> Cr-Commit-Position: refs/heads/master@{#31786}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4428
Review URL: https://codereview.chromium.org/1415783006
Cr-Commit-Position: refs/heads/master@{#31787}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31786}
If the property is a data property on the holder (or does not exist) and is a readonly data property in the receiver, then we must fail.
R=rossberg, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1424233005
Cr-Commit-Position: refs/heads/master@{#31751}
TurboFan is actually able to generate property access to all prototypes
of all primitives, except the special Oddball primitives that have no
wrapper counterparts (namely null and undefined from the ES6 point of
view).
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1409163007
Cr-Commit-Position: refs/heads/master@{#31739}
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}
