Currently we fail to properly handle shadowed properties. If the
receiver defines a non-enumerable property that reappears on the
prototype as enumerable it incorrectly shows up in [[Enumerate]].
By extending the KeyAccumulator to track non-enumerable properties
we can now properly filter them out when seeing them further up in
the prototype-chain.
BUG=v8:705
LOG=y
Review URL: https://codereview.chromium.org/1608523002
Cr-Commit-Position: refs/heads/master@{#33405}
Reason for revert:
Predecessor CL suspect for roll breakage: https://codereview.chromium.org/1610563002
Original issue's description:
> [runtime] Introduce maps for the likely cases of FromPropertyDescriptor.
>
> This change improves performance for the common case of
> Object.getOwnPropertyDescriptor by up 3x-4x, where we just
> return a property descriptor object for a regular data or
> accessor property.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/ffa9e82235b20c523ebb1151c6196bc6232296b9
> Cr-Commit-Position: refs/heads/master@{#33398}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1604243002
Cr-Commit-Position: refs/heads/master@{#33403}
This implements a first version of exception handler table construction
within the interpreter. Note that the local control flow for try-catch
and try-finally statements is still off, and also stack unwinding does
not yet respect interpreter frames. But generated handler tables should
be populated correctly already.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1607433005
Cr-Commit-Position: refs/heads/master@{#33400}
This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1607943003
Cr-Commit-Position: refs/heads/master@{#33398}
The old mechanism was a left-over from a previous time where the runtime
would rely on the presence or absence of the setter to figure out
whether or not the property is mutable. This is unnecessary by now.
Review URL: https://codereview.chromium.org/1600923002
Cr-Commit-Position: refs/heads/master@{#33377}
This adds a handler table field to the header of our BytecodeArray
objects. The field will eventually hold a range-based handler table
similar to full-codegen code, to support exception handlong within
interpreted code.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1606493002
Cr-Commit-Position: refs/heads/master@{#33373}
We can return the creation context of the [[BoundTargetFunction]], and
don't need to remember the context in which the function was bound.
R=verwaest@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1590273002
Cr-Commit-Position: refs/heads/master@{#33332}
That way, we don't have to implement the fast <-> slow migration logic,
and we don't allocate in-object properties anyways
BUG=chromium:571365
R=verwaest@chromium.org,neis@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1582773003
Cr-Commit-Position: refs/heads/master@{#33328}
Unify Object::ToObject and Execution::ToObject, and unify all users to
go to Object::ToObject directly. Also remove some dead code from the
frame details debug API.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1589323002
Cr-Commit-Position: refs/heads/master@{#33327}
That will allow for adding private symbols to JSProxies in a follow-up
change
BUG=chromium:571365
R=neis@chromium.org,verwaest@chromium.org,rossberg@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1575423002
Cr-Commit-Position: refs/heads/master@{#33241}
We use a scratchpad to remember visited allocation sites for post processing
(making tenure decisions). The previous implementation used a rooted FixedArray
with constant length (256) to remember all sites. Updating the scratchpad is a
bottleneck in any parallel/concurrent implementation of newspace evacuation.
The new implementation uses a HashMap with allocation sites as keys and
temporary counts as values. During evacuation we collect a local hashmap of
visited allocation sites. Upon merging the local hashmap back into a global one
we update potential forward pointers of compacted allocation sites. The
scavenger can directly enter its entries into the global hashmap. Note that the
actual memento found count is still kept on the AllocationSite as it needs to
survive scavenges and full GCs.
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1535723002
Cr-Commit-Position: refs/heads/master@{#33233}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
Cr-Commit-Position: refs/heads/master@{#33228}
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33231}
Reason for revert:
[Sheriff] Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/5711
Original issue's description:
> [builtins] Refactor the remaining Date builtins.
>
> This migrates the remaining Date builtins to C++ and removes obsolete
> intrinsics and JavaScript wrappers. This reduces the overhead imposed
> by the Date builtins, and will allow us to optimize them later in the
> TurboFan compiler, while the interpreter doesn't need to worry about
> them.
>
> R=yangguo@chromium.org
> BUG=chromium:576574
> LOG=n
>
> Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
> Cr-Commit-Position: refs/heads/master@{#33228}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:576574
Review URL: https://codereview.chromium.org/1574223002
Cr-Commit-Position: refs/heads/master@{#33230}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33228}
This patch implements @@species, guarded behind the --harmony-species
flag, on Arrays. Methods which return an Array will instead return
the appropriate instance based on the ArraySpeciesCreate algorithm.
The algorithm is implemented in C++ to get access to realm information
and to implement some Array methods in C++, but it is also accessed
from JavaScript through a new runtime function. A couple interactive
Octane runs show no performance regression with the flag turned off,
but turning --harmony-species on will surely have a significant
regression, as Array methods now heavily use ObjectDefineProperty.
BUG=v8:4093
LOG=Y
R=adamk,cbruni
Review URL: https://codereview.chromium.org/1560763002
Cr-Commit-Position: refs/heads/master@{#33144}
For a prototype chain foo -> global_proxy -> global_object, we used to
register a dependency from foo -> global_object. This is incorrect when
the global_proxy/global_object pairing is modified, e.g. when navigating
in iframes. With this patch, we properly register foo -> global_proxy and
global_proxy -> global_object dependencies.
Additionally, when a prototype's prototype changes from null to something
else, this new usage relation must be registered if there are other users
further down on the prototype chain that might expect a complete chain of
registrations to exist (which was the case before, and must be preserved).
BUG=chromium:571517
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1559323002
Cr-Commit-Position: refs/heads/master@{#33119}
Almost all of the Date builtins always call into C++ at least once
anyway, so parsing, compiling and executing the JavaScript wrappers
is just a waste of time. The most important part here is the Date
constructor itself, which is one of the blockers for new.target in
TurboFan, because compiling the Date constructor takes too much time
with TurboFan (for no reason since we end up in C++ anway).
R=cbruni@chromium.org
Review URL: https://codereview.chromium.org/1556333002
Cr-Commit-Position: refs/heads/master@{#33109}
There's no point in keeping the ObjectCreate JavaScript wrapper
function, which even does allocation site pretenuring for the
instances created via Object.create (where ObjectCreate itself is
the AllocationSite), and does not offer any sane way forward.
Instead introduce a new ObjectCreate C++ builtin, which currently
serves as a baseline implementation, on top of which we can think
about ways to optimize Object.create for the common case (i.e.
frameworks such as Ember.js make heavy use of Object.create).
R=cbruni@chromium.orgTBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1558433002
Cr-Commit-Position: refs/heads/master@{#33061}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33044}
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}
TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629
Review URL: https://codereview.chromium.org/1552473002
Cr-Commit-Position: refs/heads/master@{#33043}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33042}
Add API-accessors for [[ProxyTarget]], [[ProxyHandler]]. Additionally
create new proxies and revoke proxies via the API.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1542943002
Cr-Commit-Position: refs/heads/master@{#33013}
There's actually no point trying to do Function.prototype.toString in
JavaScript, as it always calls into C++ at least once, so it only
complicates things (esp. once we start optimizing bound functions).
Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
reflect the fact that these are builtins in the Function.prototype and
not on Function itself.
TBR=hpayer@chromium.orgR=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1540953004
Cr-Commit-Position: refs/heads/master@{#32996}
Introduce a new Apply builtin that forms a correct and optimizable
foundation for the Function.prototype.apply, Reflect.construct and
Reflect.apply builtins (which properly does the PrepareForTailCall
as required by the ES2015 spec).
The new Apply builtin avoids going to the runtime if it is safe to
just access the backing store elements of the argArray, i.e. if you
pass a JSArray with no holes, or an unmapped, unmodified sloppy or
strict arguments object.
mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
BUG=v8:4413, v8:4430
LOG=n
R=yangguo@chromium.org
Committed: e4d2538911
Review URL: https://codereview.chromium.org/1523753002 .
Cr-Commit-Position: refs/heads/master@{#32929}
Reason for revert:
Breaks TSAN somewhow: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7000
Original issue's description:
> [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply.
>
> Introduce a new Apply builtin that forms a correct and optimizable
> foundation for the Function.prototype.apply, Reflect.construct and
> Reflect.apply builtins (which properly does the PrepareForTailCall
> as required by the ES2015 spec).
>
> The new Apply builtin avoids going to the runtime if it is safe to
> just access the backing store elements of the argArray, i.e. if you
> pass a JSArray with no holes, or an unmapped, unmodified sloppy or
> strict arguments object.
>
> mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=v8:4413, v8:4430
> LOG=n
> R=yangguo@chromium.org
>
> Committed: e4d2538911TBR=yangguo@chromium.org,paul.lind@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4413, v8:4430
Review URL: https://codereview.chromium.org/1533803002 .
Cr-Commit-Position: refs/heads/master@{#32928}
Introduce a new Apply builtin that forms a correct and optimizable
foundation for the Function.prototype.apply, Reflect.construct and
Reflect.apply builtins (which properly does the PrepareForTailCall
as required by the ES2015 spec).
The new Apply builtin avoids going to the runtime if it is safe to
just access the backing store elements of the argArray, i.e. if you
pass a JSArray with no holes, or an unmapped, unmodified sloppy or
strict arguments object.
mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=v8:4413, v8:4430
LOG=n
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1523753002 .
Cr-Commit-Position: refs/heads/master@{#32927}
The FIRST-LAST_NONCALLABLE_SPEC_OBJECT_TYPE range was accidentially used
in field type tracking, where we should check for JSReceiver instead
(there's no need to exclude JSProxy or JSFunction from tracking).
And the use in %_ClassOf was actually wrong and didn't match the C++
implementation in JSReceiver::class_name() anymore. Now it's consistent
again.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1535523003 .
Cr-Commit-Position: refs/heads/master@{#32926}
We must print "[object Array]" for proxies that satisfy Array.isArray.
Cosmetic change on the side: move ObjectProtoToString from JSObject to Object
since it deals with arbitrary objects.
R=adamk@chromium.org, verwaest@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1526023002
Cr-Commit-Position: refs/heads/master@{#32902}
This CL makes proxy-related error messages more accurate and verbose.
(Exception: those used in deprecated functions in v8natives.js.) Some of
the old error messages were simply wrong.
On the side, fix ShouldThrow semantics of JSProxy::SetPrototype and
JSProxy::DefineOwnProperty.
R=cbruni@chromium.org, jkummerow@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1527583002
Cr-Commit-Position: refs/heads/master@{#32836}
This is necessary to guarantee that the whole descriptor would be marked, otherwise DescriptorArray pretenuring would cause crashes.
Review URL: https://codereview.chromium.org/1520613006
Cr-Commit-Position: refs/heads/master@{#32812}
The main impetus is to improve performance when --harmony-tostring
is enabled, thanks to using a generic property load instead of a
megamorphic IC.
This also reduces duplication, as the API function
v8::Object::ObjectProtoToString can share the runtime implementation.
The only functional change in this patch is to drop an accidental difference
between the JS and API implementations: the arguments object should toString
as "[object Arguments]". The JS side was corrected in
https://code.google.com/p/v8/source/detail?r=3279, but the API version was
missed in that patch.
BUG=chromium:555127, v8:3502
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1509533003
Cr-Commit-Position: refs/heads/master@{#32777}
Function subclasses did not have function properties installed (name, prototype, etc.).
Now when an instance of a Function subclass is created it gets initial map that corresponds
to the language mode of the function body. The language mode dependent maps are cached as
special transitions on initial map of the subclass constructor.
BUG=v8:4597, v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1510753005
Cr-Commit-Position: refs/heads/master@{#32764}
We either want to add code+literals to the map, or just literals.
A recent change in the structure of the map (it now uses WeakCells)
meant that we have to be more clear about what we want to do the right
thing.
BUG=
Review URL: https://codereview.chromium.org/1516833002
Cr-Commit-Position: refs/heads/master@{#32761}
In particular, return Maybe<bool> from any function that can throw, and
use MAYBE_RETURN and RETURN_FAILURE macros consistently where applicable.
No change in behavior intended.
Review URL: https://codereview.chromium.org/1513713002
Cr-Commit-Position: refs/heads/master@{#32723}
Compaction of the array with maps happens lazily upon adding new maps.
BUG=
Review URL: https://codereview.chromium.org/1481953002
Cr-Commit-Position: refs/heads/master@{#32717}
This is a simplified copy of JSObject::GetOwnElementKeys and will make it possible to eliminate the latter.
Review URL: https://codereview.chromium.org/1510083003
Cr-Commit-Position: refs/heads/master@{#32713}
Instead of iterating the whole map space to find dead transitions,
look in weak cell list and transition array list.
Simple transitions are in the weak cell list.
Full transitions are in the transitions array list.
BUG=chromium:554488
LOG=NO
Review URL: https://codereview.chromium.org/1488593003
Cr-Commit-Position: refs/heads/master@{#32684}
Error still to be done, since that's not yet available in the bootstrapper.
BUG=v8:3900, v8:3931, v8:1543, v8:3330
LOG=n
Review URL: https://codereview.chromium.org/1499923002
Cr-Commit-Position: refs/heads/master@{#32662}
- Add JSReceiver::SetIntegrityLevel, with a fast path for regular objects.
- Make Object.{freeze,seal} call this via %Object{Freeze,Seal}, thus no longer
using broken or deprecated functions from v8natives.js.
- Add JSReceiver::OwnPropertyKeys convenience function.
- Reenable harmony/proxies-hash.js test.
R=rossberg
BUG=v8:1543
LOG=N
Review URL: https://codereview.chromium.org/1489423002
Cr-Commit-Position: refs/heads/master@{#32651}
Having beefed up GetKeys() to support everything, use it for everything now.
This fixes Object.getOwnPropertyNames and Object.getOwnPropertySymbols for
Proxies, and gets rid of a bunch of code duplication.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1498593006
Cr-Commit-Position: refs/heads/master@{#32620}
For now, we revoke a proxy by setting its handler to null (as in the spec).
Change the "target" field from Object to JSReceiver as there's no point in
allowing more.
R=jkummerow@chromium.org, rossberg
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1496243003
Cr-Commit-Position: refs/heads/master@{#32608}
Reason for revert:
Seems to be (mostly) responsible for the most recent Speedometer regression, not 100% sure. Let's see what the bots have to say.
Original issue's description:
> Provide call counts for constructor calls, surface them as a vector IC.
>
> 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=
>
> Committed: https://crrev.com/66d5a9df62da458a51e8c7ed1811dc9660f4f418
> Cr-Commit-Position: refs/heads/master@{#32452}
TBR=mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1489413006
Cr-Commit-Position: refs/heads/master@{#32599}
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}