The current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355,v8:2680
Review URL: https://codereview.chromium.org/15218004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org, rossberg@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355
BUG=v8:2680
Review URL: https://codereview.chromium.org/14857009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=rossberg@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14582007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14669 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL extends the generator suspend and resume implementation to
capture values on the operand stack.
It factors out some helpers to measure and access the operand stack into
the JavaScriptFrame class. It also refactors the suspend and resume
helpers to avoid handle allocation.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14348003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14458 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes it so that suspending generators always saves the
context. Previously we erroneously assumed that if the operand stack
was empty, that the context would be unchanged, but that is not the case
with "with".
Fixing this brought out an interesting bug in the variable allocator.
Yield inside with will reference a context-allocated temporary holding
the generator object. Before the fix, this object was looked up in the
with context instead of the function context, because with contexts were
not being simulated during full-codegen. Previously this was OK as all
variables would be given LOOKUP allocation instead of CONTEXT, but the
context-allocated temporary invalidated this assumption. The fix is to
simulate the context chain more accurately in full-codegen.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14416011
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously there has been no reason to context-allocate the receiver, so
access to the receiver always goes through the stack. This was failing
with generators, which assumed that forcing context allocation would
relieve the need of storing anything but the context and the function on
the stack.
This CL adds a slot in generator objects to capture the receiver, and
restores it when resuming a generator.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14158006
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The generator object methods "next", "send", and "throw" now
include some inline assembly to set up a resumed stack frame. In some
common cases, we can just jump back into the frame to resume it.
Otherwise the resume code calls out to a runtime to fill in the operand
stack, rewind the handlers, and possibly to throw an exception.
BUG=v8:2355
TESTS=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14066016
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/ast.h:
* src/parser.cc: Differentiate between the different kinds of yields, in
anticipation of boxing return values. Parse `return' into `yield' in
a generator.
* src/runtime.h:
* src/runtime.cc (Runtime_SuspendJSGeneratorObject): New horrible
runtime function: saves continuation, context, and operands into the
generator object.
* src/arm/full-codegen-arm.cc (VisitYield):
* src/ia32/full-codegen-ia32.cc (VisitYield):
* src/x64/full-codegen-x64.cc (VisitYield): Arrange to call
SuspendJSGeneratorObject. If the call returns the hole, we suspend.
Otherwise we resume.
BUG=v8:2355
TEST=These codepaths are tested when the generator is first invoked, and so
are covered by mjsunit/harmony/generators-objects.js.
Review URL: https://codereview.chromium.org/13704010
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14353 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Generator object maps now link to their constructors, which are created
with a "Generator" class name. This does not cause a per-generator
constructor property to be set.
BUG=v8:2355
TEST=mjsunit/harmony/generators-objects
Review URL: https://codereview.chromium.org/14262004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14309 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/contexts.h:
* src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator
meta-objects, and store maps for constructing generator functions
and their prototypes.
* src/factory.h:
* src/factory.cc (MapForNewFunction): New helper.
(NewFunctionFromSharedFunctionInfo): Use the new helper.
* src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For
generators, allocate appropriate prototypes and maps.
* src/code-stubs.h:
* src/arm/code-stubs-arm.h:
* src/arm/full-codegen-arm.h:
* src/ia32/code-stubs-ia32.h:
* src/ia32/full-codegen-ia32.h:
* src/x64/code-stubs-x64.h:
* src/x64/full-codegen-x64.h: Allow fast closure creation for generators,
using the appropriate map.
* test/mjsunit/harmony/builtins.js: Add a special case for
GeneratorFunctionPrototype.prototype.__proto__.
BUG=
TEST=mjsunit/harmony/generators-runtime
Review URL: https://codereview.chromium.org/13192004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/scopes.h (ForceContextAllocation, has_forced_context_allocation):
New interface to force context allocation for an entire function's
scope.
* src/scopes.cc: Unless a new scope is a function scope, if its outer
scope has forced context allocation, it should also force context
allocation.
(MustAllocateInContext): Return true if the scope as a whole has
forced context allocation.
(CollectStackAndContextLocals): Allow temporaries to be
context-allocated.
* src/parser.cc (ParseFunctionLiteral): Force context allocation for
generator scopes.
* src/v8globals.h (VariableMode): Update comment on TEMPORARY.
* src/arm/full-codegen-arm.cc (Generate):
* src/ia32/full-codegen-ia32.cc (Generate):
* src/x64/full-codegen-x64.cc (Generate): Assert that generators have no
stack slots.
* test/mjsunit/harmony/generators-instantiation.js: New test.
BUG=v8:2355
TEST=mjsunit/harmony/generators-instantiation
Review URL: https://codereview.chromium.org/13408005
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14152 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patchset begins by adding support for "yield", which is unlike other tokens
in JS. In a generator, whether strict or classic, it is a syntactic keyword.
In classic mode it is an identifier. In strict mode it is reserved.
This patch adds YIELD as a token to the scanner, and adapts the preparser and
parser appropriately. It also parses "function*", indicating that a function is
actually a generator, for both eagerly and lazily parsed functions.
Currently "yield" just compiles as "return".
BUG=v8:2355
TEST=mjsunit/harmony/generators-parsing
Review URL: https://codereview.chromium.org/12646003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14116 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(qua last week's TC39)
Specifically:
- Install Symbol constructor function on the global object.
- Adjust code generation for typeof.
- Remove IsSymbol built-in, IS_SYMBOL macro now defined using typeof.
- Remove hack that allowed symbols as constructor results, and some other special cases.
- Remove symbol_delegate and GetDelegate function.
- Extend ToBoolean stub to handle symbols.
- Extend ToNumber to return NaN on symbols.
- Poison symbol's toString function, and thereby ToString on symbols.
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12957004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This moves the __proto__ property to Object.prototype and turns it into
a callback property actually present in the descriptor array as opposed
to a hack in the properties lookup. For now it still is a "magic" data
property using foreign callbacks and not an accessor property visible to
JavaScript.
The second effect of this change is that JSON.parse() no longer treats
the __proto__ property specially, it will be defined as any other data
property. Note that object literals still have their special handling.
R=rossberg@chromium.org
BUG=v8:621,v8:1949,v8:2441
TEST=mjsunit,cctest,test262
Review URL: https://codereview.chromium.org/12212011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13728 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a data property has its attributes changed but its value remains the same,
don't emit an oldValue. This makes the API more consistent by only emitting
oldValue when the value of a property has actually changed (or been removed,
in the case of a reconfiguration as an accessor property or a deletion).
Review URL: https://codereview.chromium.org/11820004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13565 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The approach in this change is to handle the unwrapping/wrapping of the global object transparently with respect to the JS implementation of Object.observe. An alternate approach would be to add a runtime method like %IsJSGlobalProxy and %UnwrapJSGlobalProxy, but it seems ugly to give JS (even implementation JS) access to the unwrapped global.
BUG=v8:2409
Review URL: https://codereview.chromium.org/11414094
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)
All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.
For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,
module A {
let x;
module B { let y; }
}
module C { let z; }
allocates contexts as follows:
[header| .A | .B | .C | A | C ] (global)
| | |
| | +-- [header| z ] (module)
| |
| +------- [header| y ] (module)
|
+------------ [header| x | B ] (module)
Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).
To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.
1. Allocate: for each module _literal_, allocate the module contexts and
respective instance object and wire them up. This happens in the
PushModuleContext runtime function, as generated by AllocateModules
(invoked by VisitDeclarations in the hosting scope).
2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
assign the respective instance object to respective local variables. This
happens in VisitModuleDeclaration, and uses the instance objects created
in the previous stage.
For each module _literal_, this phase also constructs a module descriptor
for the next stage. This happens in VisitModuleLiteral.
3. Populate: invoke the DeclareModules runtime function to populate each
_instance_ object with accessors for it exports. This is generated by
DeclareModules (invoked by VisitDeclarations in the hosting scope again),
and uses the descriptors generated in the previous stage.
4. Initialize: execute the module bodies (and other code) in sequence. This
happens by the separate statements generated for module bodies. To reenter
the module scopes properly, the parser inserted ModuleStatements.
R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11093074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These were erroneously disabled because they were expecting indexed properties to be of Number type when appearing as the "name" in change records. But the "name" property will always be a string. Fixed assertRecordsEqual() to enforce this in expectations.
BUG=v8:2409
Review URL: https://codereview.chromium.org/11280105
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13027 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The previous implementation in Accessors::ArraySetLength failed when array length was set through StoreIC_ArrayLength. But that stub and the accessor both delegate to JSArray::SetElementsLength, so moving the code there allows notifications to be sent in both cases.
Review URL: https://codereview.chromium.org/11275292
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12962 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
