In an initial attempt to implement sloppy mode lexical bindings,
functions were made lexically scoped in sloppy mode. However, the
ES2015 spec says that they need an additional hoisted var binding,
and further, it's not clear when we'll implement that behavior
or whether it's web-compatible.
This patch splits off function block scoping into a new, separate
flag called --harmony_sloppy_function. This change will enable the
possibility of testing and shipping this feature separately from
other block scoping-related features which don't have the same risks.
BUG=v8:4285
R=adamk
LOG=N
Review URL: https://codereview.chromium.org/1282093002
Cr-Commit-Position: refs/heads/master@{#30122}
This way we can greatly simplify the different variants of ToObject in
our codebase and make them more uniform and robust. Adding a new
primitive doesn't require finding and changing all those places again,
but it is sufficient to setup the constructor function index when
allocating the map.
We use the inobject properties field of Map, which is invalid primitive
maps anyway.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1276533003
Cr-Commit-Position: refs/heads/master@{#30119}
There's no need to have one InstanceType per SIMD primitive type (this
will not scale long-term). Also reduce the amount of code duplication
and make it more robust wrt adding new SIMD types.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1273353003
Cr-Commit-Position: refs/heads/master@{#30107}
This avoids many back-and-forth calls to the runtime.
This also slightly changes the way we avoid getters. Previously, we circumvent getting the name property of ReferenceError, SyntaxError and TypeError due to crbug/69187 (in order to avoid leaking information from those errors through a 'name' getter installed on their prototypes). Now we do that for all errors created by V8.
R=jkummerow@chromium.org, rossberg@chromium.org
BUG=crbug:513472, crbug:69187
LOG=N
Review URL: https://codereview.chromium.org/1281833002
Cr-Commit-Position: refs/heads/master@{#30105}
No need to provide TO_INT32/TO_UINT32 functions for every native
context, as they can be implemented in terms of TO_NUMBER more easily
and efficiently.
Also remove the obsolete TO_BOOLEAN_FUN_INDEX from the native contexts.
Review URL: https://codereview.chromium.org/1275013004
Cr-Commit-Position: refs/heads/master@{#30080}
The heuristic can cause weird behavior when bootstrapping.
The memory savings is not worth this hassle.
Review URL: https://codereview.chromium.org/1265983006
Cr-Commit-Position: refs/heads/master@{#30019}
To avoid tanking context startup performance, only the actual installation of the
JS-exposed API is flag-guarded. The remainder of the implementation still
resides in the snapshot.
Review URL: https://codereview.chromium.org/1257063003
Cr-Commit-Position: refs/heads/master@{#30017}
The heuristic can cause weird behavior when bootstrapping.
The memory savings is not worth this hassle.
Review URL: https://codereview.chromium.org/1265983006
Cr-Commit-Position: refs/heads/master@{#29992}
There is only one use case for it: String.prototype.search converts a
string argument into a RegExp. The cache is used to avoid repeating that
conversion. However, this does not make the added complexity worthwhile.
Review URL: https://codereview.chromium.org/1267493006
Cr-Commit-Position: refs/heads/master@{#29985}
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}
We can apply the shortcut used for data properties of the JSGlobalObject
to builtin properties as well. This mostly affects the custom properties
we use for the Math functions (i.e. rngstate for Math.random() and kMath
for sin, cos and friends).
Drive-by-fix: Also mark the internal builtin typed arrays properties
(rngstate, kMath and rempio2result) as READ_ONLY, as they should not be
touched after genesis.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1254143003
Cr-Commit-Position: refs/heads/master@{#29887}
--harmony_sloppy includes behavior to turn on sloppy mode lexical
bindings. Before this patch, it also included a way to parse let
which is likely web-incompatible (let is disallowed as an
identifier). This patch splits off the let parsing from the more
general block scoping code, so that block scoping can be developed
independently.
R=adamk
LOG=N
BUG=v8:3305
Review URL: https://codereview.chromium.org/1255013002
Cr-Commit-Position: refs/heads/master@{#29855}
This implements the missing %DefaultConstructorCallSuper runtime
functionality, thereby allowing all compilers to fall-back to that
implementation when the appropriate intrinsic is missing.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1240993002
Cr-Commit-Position: refs/heads/master@{#29753}
We should not install the SIMD object on the global object unless
support for SIMD is actually turned on by the flag. Otherwise calling
SIMD.Float32x4() will hit unreachable code. We accidentally SIMD.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1240223002
Cr-Commit-Position: refs/heads/master@{#29749}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
where bound functions started overriding the "name" accessor property with a data property. The bootstrapper must be kept in sync to avoid polymorphism.
BUG=chromium:509983
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1238903002
Cr-Commit-Position: refs/heads/master@{#29685}
Until now, TF-generated code stubs piggy-backed off of the builtin
context. Since generation of code stubs is lazy, stubs generated at
different times in different native contexts would contain embedded
pointers different builtin contexts, leading to cross-context references
and memory leaks.
After this CL, all TF-generated code stubs are generated inside a
internal thinned-out, native context that lives solely for the
purpose of hosting generated code stubs.
Review URL: https://codereview.chromium.org/1213203007
Cr-Commit-Position: refs/heads/master@{#29593}
Note that there are currently no objects that require a pre-allocated
properties backing store, all such slots are in-object properties from
the begining. Hence {unused + pre_allocated - inobject == 0} holds.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1226203011
Cr-Commit-Position: refs/heads/master@{#29590}
The breakage to Chrome seems to be based on @@isConcatSpreadable
and turning that part off with this patch fixes the Maps Tips & Tricks
test case.
BUG=chromium:507553
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1226063002
Cr-Commit-Position: refs/heads/master@{#29545}
where bound functions' length was made configurable. The bootstrapper must be kept in sync to avoid polymorphism.
BUG=chromium:500686
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1221383003
Cr-Commit-Position: refs/heads/master@{#29496}
Conditionally including Array and TypedArray methods seems to cause
a slowdown in V8 context creation, possibly due to the new code added.
BUG=chromium:504629
R=adamk@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1215863003
Cr-Commit-Position: refs/heads/master@{#29430}
Speculative revert in the hopes of fixing serializer crashes seen in canary.
This reverts commit c166945083, as well as
followup change "Do not look for existing shared function info when compiling a new script."
(commit 7c43967bb7).
BUG=chromium:503552,v8:4132
TBR=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1207583002
Cr-Commit-Position: refs/heads/master@{#29241}
Map: get, set, has, delete, clear
Set: add, has, delete, clear
All except clear are implemented as calls into collection.js.
Note that some of these shadow methods of v8::Object. It's unclear
how confusing that's going to be: on the one hand, it seems likely
that most operations you would want to do on a Map or Set are these.
On the other, generic code could get confused if it somehow gets
ahold of a variable that happens to be C++-typed as a v8::Map or v8::Set.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1204623002
Cr-Commit-Position: refs/heads/master@{#29237}
Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
objects created from this script.
This way, when compiling a function, we do not create duplicate shared
function info objects when recompiling with either compiler.
This fixes a class of issues in the debugger, where we set break points
on one shared function info, but functions from duplicate shared function
infos are not affected.
LOG=N
BUG=v8:4132
Review URL: https://codereview.chromium.org/1183733006
Cr-Commit-Position: refs/heads/master@{#29151}
Reason for revert:
Blocks revert of https://codereview.chromium.org/1175973002
Original issue's description:
> Replace SetObjectProperty / DefineObjectProperty with less powerful alternatives where relevant.
>
> @yangguo: please look at the debugger part of the CL.
> @ishell: please look at the rest.
>
> Additionally:
> - Ensure the LookupIterator for named properties does not accidentally get indexes in.
> - Fix the return value for typed array assignments to be the incoming value.
>
> BUG=v8:4137
> LOG=n
>
> Committed: https://crrev.com/15aa811f8fe2708a757c3b53ca89db736aa8b222
> Cr-Commit-Position: refs/heads/master@{#28954}
TBR=yangguo@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4137
Review URL: https://codereview.chromium.org/1181733002
Cr-Commit-Position: refs/heads/master@{#28957}
@yangguo: please look at the debugger part of the CL.
@ishell: please look at the rest.
Additionally:
- Ensure the LookupIterator for named properties does not accidentally get indexes in.
- Fix the return value for typed array assignments to be the incoming value.
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1178503004
Cr-Commit-Position: refs/heads/master@{#28954}
The Map and Set maps get overwritten when collection.js executes, so in
a nosnap build we have to wait until it runs before we grab the maps.
To facilitate that, store the functions in the native context as well.
Review URL: https://codereview.chromium.org/1161363002
Cr-Commit-Position: refs/heads/master@{#28743}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
Stage 1 implementation:
- Parameters can't be referenced before initialized (from left-to-right)
- SingleNameBindings only, no support for BindingPatterns
Known issues:
- Incorrect scoping (parameter expressions may reference variables declared in function body)
- Function arity is untouched
- Hole-checking needs work
- Rest parameters are broken when mixed with optional arguments
BUG=v8:2160
LOG=N
R=arv@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1127063003
Cr-Commit-Position: refs/heads/master@{#28739}
Strong Object/Array literals are currently being created with incorrect
internal prototypes. This CL fixes this and extends the test suite to check.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1158933002
Cr-Commit-Position: refs/heads/master@{#28655}
These are similar to the Map/Set constructors when called with an array,
except that they are guaranteed to be side-effect free if called with
a packed array.
This will be useful in implementing structured clone which, as
specified in HTML, speaks in terms of the internal [[MapData]]
and [[SetData]] slots without going through the exposed iteration
ES semantics.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1155893003
Cr-Commit-Position: refs/heads/master@{#28642}
The April 14 2015 final draft of the ES6 specification states that the
`prototype` property of generator function instances should be writable.
BUG=v8:4140, v8:4140
LOG=N
R=arv@chromium.org
Review URL: https://codereview.chromium.org/1153633003
Cr-Commit-Position: refs/heads/master@{#28641}
Only supports constructing new objects and returning size.
Followup patch will need to add ability to retrieve and
set contents in order to support structured clone.
Also removes a bunch of outdated "experimental" markers from v8.h.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1157453002
Cr-Commit-Position: refs/heads/master@{#28637}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28594}
Reason for revert:
breaks build
Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1149203003
Cr-Commit-Position: refs/heads/master@{#28589}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28588}
This allows you to put iterables into your array literals
and the will get spread into the array.
let x = [0, ...range(1, 3)]; // [0, 1, 2]
This is done by treating the array literal up to the first
spread element as usual, including using a boiler plate
array, and then appending the remaining expressions and rest
expressions.
BUG=v8:3018
LOG=N
Review URL: https://codereview.chromium.org/1125183008
Cr-Commit-Position: refs/heads/master@{#28534}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Committed: https://crrev.com/7a599c5e1242d3c5ab7515ee149623da90ae69ec
Cr-Commit-Position: refs/heads/master@{#28445}
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28459}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28445}
All the builtin iterators as well as the generator objects have an
object called %IteratorPrototype% in the spec between them and
%ObjectPrototype%.
BUG=v8:3568
LOG=N
Review URL: https://codereview.chromium.org/1128233008
Cr-Commit-Position: refs/heads/master@{#28426}
We keep an eye on the recursion depth. Once it exceeds a limit, we serialize
only the object header and size, but defer serializing the object body for
after we have unwound the stack.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1125073004
Cr-Commit-Position: refs/heads/master@{#28385}
Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
BUG=chromium:481845
LOG=Y
Review URL: https://codereview.chromium.org/1134193002
Cr-Commit-Position: refs/heads/master@{#28371}
