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}
Reason for revert:
GC mole issues: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gcmole/builds/1950/steps/GCMole%20ia32/logs/stdio
Original issue's description:
> Provide accessor for object internal properties that doesn't require debugger to be active
>
> 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
>
> Committed: https://crrev.com/bdeb0de88c8cf5f2c78f261b45314138f525110d
> Cr-Commit-Position: refs/heads/master@{#28362}
TBR=pfeldman@chromium.org,kozyatinskiy@chromium.org,yurys@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:481845
Review URL: https://codereview.chromium.org/1133243002
Cr-Commit-Position: refs/heads/master@{#28365}
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/1126103006
Cr-Commit-Position: refs/heads/master@{#28362}
For the moment, we only pass the global object (the one we are setting up).
A few smaller changes were necessary to avoid failures in
test-object-observe/DontLeakContextOnObserve. Otherwise the global object
would be retained by being context allocated, leading to test failure.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1132513003
Cr-Commit-Position: refs/heads/master@{#28331}
Exposed to the extras as extrasExports (on the builtins object), on
which they can put things that should be accessible from C++. Exposed
to C++ through the V8 API as v8::Context::GetExtrasExportsObject().
Adding a test (in test-api.cc) required adding a simple extra,
test-extra.js, which we build into the standalone builds.
R=yangguo@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1128113006
Cr-Commit-Position: refs/heads/master@{#28317}
Instead of making them an extra option that gets passed in and compiled
at the end of the natives file for a given run of js2c, we now make them a
separate run of js2c with a separate natives file output.
This natives file output is then compiled in the bootstrapper. It is not part
of the snapshot (yet), but instead is treated similar to the experimental
natives, just without any of the complexity that comes from tieing the
behavior to flags. We also don't need counterparts to
InitializeExperimentalGlobal and InstallExperimentalNativeFunctions (yet?).
This fixes the issue with https://codereview.chromium.org/1129743003 by making
the dummy file that is generated for snapshots with no extras (or no experimental
features) nonempty.
R=yangguo@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1130993003
Cr-Commit-Position: refs/heads/master@{#28311}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/2745
Original issue's description:
> Make V8 extras a separate type of native
>
> Instead of making them an extra option that gets passed in and compiled
> at the end of the natives file for a given run of js2c, we now make them a
> separate run of js2c with a separate natives file output.
>
> This natives file output is then compiled in the bootstrapper. It is not part
> of the snapshot (yet), but instead is treated similar to the experimental
> natives, just without any of the complexity that comes from tieing the
> behavior to flags. We also don't add counterparts to
> InitializeExperimentalGlobal and InstallExperimentalNativeFunctions, yet.
>
> R=yangguo@chromium.org, jochen@chromium.org
> BUG=
>
> Committed: https://crrev.com/c93aff4ac63ad9ffb6318e750335208de32b7902
> Cr-Commit-Position: refs/heads/master@{#28296}
TBR=jochen@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1131903002
Cr-Commit-Position: refs/heads/master@{#28299}
Instead of making them an extra option that gets passed in and compiled
at the end of the natives file for a given run of js2c, we now make them a
separate run of js2c with a separate natives file output.
This natives file output is then compiled in the bootstrapper. It is not part
of the snapshot (yet), but instead is treated similar to the experimental
natives, just without any of the complexity that comes from tieing the
behavior to flags. We also don't add counterparts to
InitializeExperimentalGlobal and InstallExperimentalNativeFunctions, yet.
R=yangguo@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1129743003
Cr-Commit-Position: refs/heads/master@{#28296}
Just give internal ones an ArrayBuffer with a NULL backing store. This
simplifies the access checks a lot.
BUG=v8:3996
R=hpayer@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1109353003
Cr-Commit-Position: refs/heads/master@{#28168}
We shouldn't have shared state between isolates by default. The embedder
is free to pass the same allocator to all isolates it creates.
BUG=none
R=dcarney@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1116633002
Cr-Commit-Position: refs/heads/master@{#28127}
ES6 specifies the function name property (it was not part of ES5) and
it specifies the name of Function.prototype to the empty string ("" and
not "Empty"). This makes us match Firefox, Safari and IE developer
preview.
BUG=v8:4033
LOG=N
R=adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1080393004
Cr-Commit-Position: refs/heads/master@{#28021}
In ES6 function name and length are configurable. However, the length
and name properties of the poison pill function must not be
configurable.
BUG=v8:4011
LOG=N
R=adamk@chromium.org, rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1061393002
Cr-Commit-Position: refs/heads/master@{#27855}
This avoids both a mysterious boolean argument ("insert") and lets
non-mutating lookups skip passing an allocator (in one such case,
we were passing a scary-looking ZoneAllocationPolicy(NULL)!).
Review URL: https://codereview.chromium.org/1074943002
Cr-Commit-Position: refs/heads/master@{#27799}
When ObjectToString is installed on Object.prototype twice (once in v8natives.js, and once in harmony-tostring.js), this pollutes old code spaces on some devices. To prevent this, the function is only installed once, preventing test failures when the --harmony-tostring flag is flipped on by default.
BUG=v8:3502
LOG=N
R=arv@chromium.org
Review URL: https://codereview.chromium.org/1072083002
Cr-Commit-Position: refs/heads/master@{#27720}
Escaping used to happen lazily, implemented in an accessor property.
However, native implementation of RegExp methods use .source as well.
This leads to performance regressions. Now we do it eagerly instead.
R=jkummerow@chromium.org
BUG=chromium:436447
LOG=N
Review URL: https://codereview.chromium.org/1070093002
Cr-Commit-Position: refs/heads/master@{#27705}
The motivation is that we prefer to avoid creating internal properties, and we have a usable field on maps ("transitions", which is not used for prototype maps).
This CL also ensures the invariant that prototype maps are never shared, even if they are in dictionary mode.
Review URL: https://codereview.chromium.org/1033653002
Cr-Commit-Position: refs/heads/master@{#27617}
From ES6 25.2.3 ("Properties of the GeneratorFunction Prototype
Object"):
> The GeneratorFunction prototype object is an ordinary object. It is
> not a function object and does not have an [[ECMAScriptCode]] internal
> slot or any other of the internal slots listed in Table 27 or Table
> 56.
Introduce one assertion for the value's type and additional tests for its
properties. Remove an invalid assertion that fails as a result of this
fix.
BUG=v8:3991
LOG=N
Review URL: https://codereview.chromium.org/1062633002
Cr-Commit-Position: refs/heads/master@{#27603}
The cause was dynamic allocation of an accounting structure used to
create/initialize the type feedback vector, done at the end of the
numbering pass. The solution is to Zone-allocate the structure to
bring it's lifetime in line with the compilation unit.
BUG=
Review URL: https://codereview.chromium.org/1014793003
Cr-Commit-Position: refs/heads/master@{#27241}
ES6 specs the function length property (it was not part of ES5) and
it makes it configurable.
BUG=v8:3045
LOG=N
R=mstarzinger@chromium.org, adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/993073002
Cr-Commit-Position: refs/heads/master@{#27190}
According to Source Map specification [1] source map url can be passed either as a magic comment at the end of script or as SourceMap http header. We already parse the former value and expose it on Script object. This change allows to unify the way we deal with source map urls received in http header by providing api for passing that url into the script being compiled.
source_map_url is intentionally not passed into CompilationCacheScript::Lookup. The cache is anyways disabled when debugger is on.
[1] https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
LOG=Y
BUG=chromium:462572
Review URL: https://codereview.chromium.org/983603003
Cr-Commit-Position: refs/heads/master@{#27017}
Function name property is now standardized in ES6. It was a Mozilla proprietary
extension before. With ES6, the property was made configurable, so that it can
be used instead of another proprietary property, displayName.
This is a revert of revert c791d84112.
Last time this broke a Chrome browser test which has since been updated:
5f75a3be4c
BUG=v8:3333
LOG=N
R=mstarzinger@chromium.org,verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/977003004
Cr-Commit-Position: refs/heads/master@{#26996}
Experimental globals are simply flag values on the builtins object to
turn on/off harmony features. We still need to declare them even when
we don't turn on harmony features for the snapshot.
R=vogelheim@chromium.org
Review URL: https://codereview.chromium.org/978813002
Cr-Commit-Position: refs/heads/master@{#26992}
Re-installing experimental natives after deserialization causes failures if
said experimental native is already included in the snapshot. However, there
is no way to tell whether a certain harmony feature has been included.
Experimental natives may also be turned on/off on-demand, which a snapshot
that includes them would not support for all cases.
The simple solution for the meantime is to never include experimental natives
in the snapshot and initialize them after deserialization on-demand.
R=vogelheim@chromium.org
Review URL: https://codereview.chromium.org/981473002
Cr-Commit-Position: refs/heads/master@{#26982}
This is partially based on r21609 but that CL was incomplete.
Function name is still non writable so one has to use defineProperty
to change the actual value.
BUG=v8:3333
LOG=N
R=adamk, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/960343002
Cr-Commit-Position: refs/heads/master@{#26924}
InstallBuiltinFunctionIds stood out when looking at code that grew
strangely when compiled with default optimizations.
This change from repeated code to a loop saves 6-7 KB of machine code.
I suspect it's faster but I also suspect it's fast enough either way so
that is not really a factor. Machine code reduction seen below.
Code formatted with git cl format.
clang x64:
Total change: -5985 bytes
-------------------------------------------
+517 - Source: ?? - (gained 744, lost 227)
-------------------------------------------
New symbols:
+744: v8::internal::Genesis::InstallBuiltinFunctionIds()::builtins type=d, size=744 bytes
Removed symbols:
-4: .L.str98 type=r, size=4 bytes
... [stripped 30 similar lines]
-19: .L.str100 type=r, size=19 bytes
----------------------------------------------------------------------------------------------
-6502 - Source: /home/bratell/src/chromium/src/v8/src/bootstrapper.cc - (gained 0, lost 6502)
----------------------------------------------------------------------------------------------
Removed symbols:
-1135: v8::internal::ResolveBuiltinIdHolder(v8::internal::Handle<v8::internal::Context>, char const*) type=t, size=1135 bytes
Shrunk symbols:
-5367: v8::internal::Genesis::InstallBuiltinFunctionIds() type=t, (was 7105 bytes, now 1738 bytes)
BUG=
Review URL: https://codereview.chromium.org/918303005
Cr-Commit-Position: refs/heads/master@{#26919}
Function.prototype.toMethod was removed from ES6.
This removes the function and updates the tests to either
use %ToMethod or a dedicated syntax (using concise method
or a class).
BUG=v8:3330
LOG=N
R=dslomov@chromium.org, adamk
Review URL: https://codereview.chromium.org/914713002
Cr-Commit-Position: refs/heads/master@{#26559}
This adds an "experimental" API hook (v8::ScriptCompiler::CompileModule)
allowing compilation of modules. The code gen is incredibly basic: the
module body is represented by a Block in the AST. But this at least gets
more of the pipeline working, and opens the door to writing mjsunit tests
(once d8 is modified to support module compilation).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/902093002
Cr-Commit-Position: refs/heads/master@{#26496}
This way we can ship \u{..} escapes in strings / identifiers before shipping /u
regexps.
BUG=
Review URL: https://codereview.chromium.org/903703002
Cr-Commit-Position: refs/heads/master@{#26461}
When embedder detaches the global objects, its context must be garbage
collected eventually.
BUG=
Review URL: https://codereview.chromium.org/898663005
Cr-Commit-Position: refs/heads/master@{#26450}
In DevTools we need one more flag for script origin - is debugger script. We already have "is shared origin" flag. The new flag added by analogy with the old but new has accessor in script object.
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/879553002
Cr-Commit-Position: refs/heads/master@{#26324}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, 7d48fd9dc2.
BUG=v8:3754
LOG=Y
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/798243004
Cr-Commit-Position: refs/heads/master@{#26084}
Math functions:
Some Math functions require typed arrays for their implementation. The embedded
script may call those Math functions. The serializer needs to deal with this.
Added assertion to make sure no other typed array is created when snapshotting.
Number-string cache:
We assume that the initial snapshot does not expand the number-string cache.
This is no longer true for custom heap snapshots.
Bound functions:
Bound functions store the bound arguments in a COW fixed array, including the
bindee function. COW arrays are serialized into the startup snapshot and
referenced in the partial snapshot via partial snapshot cache. However, the
bindee function is context-dependent and must not be part of the startup
snapshot. There is no need for bound functions to use a COW array though.
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/851073002
Cr-Commit-Position: refs/heads/master@{#26072}
R=jochen@chromium.org
TEST=test-serialize/CustomContext{Des,S}erialization
Also test by
- make ia32.debug embedscript=<full path to mjsunit.js>
- d8 -e "assertDoesNotThrow('print(1)')"
Review URL: https://codereview.chromium.org/846023002
Cr-Commit-Position: refs/heads/master@{#26035}
Reason for revert:
[sheriff] Still crashes on win32 (XP):
http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%201/builds/1380
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4.
>
> This changes to do an early bailout in
> HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
> loop.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org,arv@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/811593004
Cr-Commit-Position: refs/heads/master@{#25872}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4.
This changes to do an early bailout in
HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
loop.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/792233008
Cr-Commit-Position: refs/heads/master@{#25868}
Reason for revert:
Crashes Win32. It was not flake.
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4 with
> no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
> try again.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/807033003
Cr-Commit-Position: refs/heads/master@{#25853}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4 with
no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
try again.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/807173002
Cr-Commit-Position: refs/heads/master@{#25851}
There are no users of this infrastructure yet, so it's behind an off-by-default flag.
Review URL: https://codereview.chromium.org/768633002
Cr-Commit-Position: refs/heads/master@{#25829}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
BUG=v8:3754
LOG=Y
Review URL: https://codereview.chromium.org/795573005
Cr-Commit-Position: refs/heads/master@{#25821}
These methods for used for compressed libraries, where GetSource* functions
contained the compressed sources and [GS]etRawSource* the uncompressed
sources. This is dead code since the API no longer supports compression.
(If you need/want compressed sources, use the external startup data and
compress/uncompress on the Embedder's side.)
BUG=
Review URL: https://codereview.chromium.org/772853003
Cr-Commit-Position: refs/heads/master@{#25666}
As there's no associated bug, here's the issue:
- Some ES6 functionality in Chrome is presently broken; this fixes it.
- The natives (built-in libraries) can be accessed by their 'name'.
This is used to active ES6 flags.
- Strangely enough, there's an id and a name, where the name is derived
from the id as "native %s.js", with %s for the id.
- NativesCollection<.>::GetScriptName uses the name.
- NativesCollection<.>::GetIndex uses the id.
- Example:
NativesCollection<EXPERIMENTAL>::GetIndex("harmony-string") -> 3
NativesCollection<EXPERIMENTAL>::GetScriptName(3) -> "native harmony-string.js"
- Nobody knows why; it's quite mysterious.
- When introducing the "external startup data", I didn't fully understand this
and used the id in both places.
- When the "external startup data" was turned on in Chrome, ES6 features broke
in Chrome since the libraries could no longer be found.
- This CL fixes this and makes the external startup data behave just like the
built-in version.
R=dslomov
BUG=
Review URL: https://codereview.chromium.org/774613003
Cr-Commit-Position: refs/heads/master@{#25624}
First step towards replacing PropertyType with two enums: {DATA,ACCESSOR} x {CONST,WRITABLE}.
Review URL: https://codereview.chromium.org/733253004
Cr-Commit-Position: refs/heads/master@{#25417}
This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.
When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable
Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.
R=adamk@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/705663004
Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is in preparation for making --harmony and --es-staging synonyms.
The only remaining difference currently is block-scoping, which is still
implied by --harmony, to avoid regressing on a long-available feature.
Also removes the special-casing of --harmony-proxies.
R=adamk@chromium.org
BUG=
Review URL: https://codereview.chromium.org/693153004
Cr-Commit-Position: refs/heads/master@{#25115}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25115 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Updates Object.prototype.toString() to use algorithm described in harmony drafts.
Currently, the behaviour is essentially the same as ES262's version, however this changes when internal structures
such as Promise make use of symbolToStringTag (as they are supposed to, see v8:3241), and changes further once
Symbol.toStringTag is exposed publicly.
BUG=v8:3241, v8:3502
LOG=N
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/546803003
Patch from Caitlin Potter <caitpotter88@gmail.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
> We also initialize the Isolate on creation.
>
> This should allow for getting rid of the last remaining default isolate
> traces. Also, it'll speed up several isolate related operations that no
> longer require locks.
>
> Embedders that relied on v8::Isolate to return an uninitialized Isolate
> (so they can set ResourceConstraints for example, or set flags that
> modify the way the isolate is created) should either do the setup before
> creating the isolate, or use the recently added CreateParams to pass e.g.
> ResourceConstraints.
>
> BUG=none
> LOG=y
> R=svenpanne@chromium.org
>
> Review URL: https://codereview.chromium.org/469783002
BUG=none
LOG=y
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/583153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We also initialize the Isolate on creation.
This should allow for getting rid of the last remaining default isolate
traces. Also, it'll speed up several isolate related operations that no
longer require locks.
Embedders that relied on v8::Isolate to return an uninitialized Isolate
(so they can set ResourceConstraints for example, or set flags that
modify the way the isolate is created) should either do the setup before
creating the isolate, or use the recently added CreateParams to pass e.g.
ResourceConstraints.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/469783002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Causes a flaky failure on buildbots. Here is the (deterministic) repro step (thanks to Michael Stanton):
first go to flag-definitions.h and set this to false.
DEFINE_BOOL(enable_sse4_1, false,
"enable use of SSE4.1 instructions if available")
Run the following and it should fail:
tools/run-tests.py --arch=ia32 --mode=release cctest/test-api/Regress2107
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/580123002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24045 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
