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
- Addition of a compiled hydrogen stub for KeyedStores.
- Inlining of "grow" stubs into OPTIMIZED_FUNCTIONs
- Addition of new "ignore OOB" ic stub that silently swallows out-of-bounds stores to external typed arrays.
- Addition of new "copy-on-write" ic stub that inlines allocation and copying operations for cow array
- New stub are generated with Crankshaft, so they are automatically inlined into OPTIMIZED_FUNCTIONs
Review URL: https://codereview.chromium.org/12221064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14001 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 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
Currently only simple getter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the getter is not
handled at all. Because of the latter, we temporarily hide this feature behind a
new flag --inline-accessors, which is false by default.
Review URL: https://chromiumcodereview.appspot.com/10828066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Specifically:
- In parser, check that all exports are defined.
- Move JSModule allocation from parser to scope resolution.
- Move JSModule linking from full codegen to scope resolution.
- Implement module accessors for exported value members.
- Allocate module contexts statically along with JSModules
(to allow static linking), but chain them when module literal is evaluated.
- Make module contexts' extension slot refer to resp. JSModule
(makes modules' ScopeInfo accessible from context).
- Some other tweaks to context handling in general.
- Make any code containing module literals (and thus embedding
static references to JSModules) non-cacheable.
This enables accessing module instance objects as expected.
Import declarations are a separate feature and do not work yet.
R=mstarzinger@chromium.org
BUG=v8:1569
TEST=
Review URL: https://chromiumcodereview.appspot.com/10690043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The CompilationInfo record now saves a Zone, and the compiler pipeline
allocates memory from the Zone in the CompilationInfo. Before
compiling a function, we create a Zone on the stack and save a pointer
to that Zone to the CompilationInfo; which then gets picked up and
allocated from.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10534139
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This changes the compiler to be more aggressive about lazy compilation
of closures with non-trivial outer context. Compilation can only be
triggered with a valid outer context now. One exception is the debugger,
which can request compilation of arbitrary shared code, but it ensures
to trigger compilation only at points where no context is needed.
This relands r11782, r11783, r11790 and a minor fix.
R=ulan@chromium.org
TEST=mjsunit/debug-script-breakpoints-nested
Review URL: https://chromiumcodereview.appspot.com/10543141
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This changes the compiler to be more aggressive about lazy compilation
of closures with non-trivial outer context. Compilation can only be
triggered with a valid outer context now. One exception is the debugger,
which can request compilation of arbitrary shared code, but it ensures
to trigger compilation only at points where no context is needed.
R=ulan@chromium.org
TEST=mjsunit/debug-script-breakpoints-nested
Review URL: https://chromiumcodereview.appspot.com/10538102
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11782 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).
Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
and for populating instance objects from module literals.
Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
(macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.
Baseline: http://codereview.chromium.org/9722043/R=svenpanne@chromium.org,mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To do this, we collect all accessor properties in a first pass and emit code for
defining those properties afterwards in a second pass.
As a finger exercise, the table used for collecting accessors has a (subset of
an) STL-like iterator interface, including STL-like names and operators.
Although C++ is quite verbose here (as usual, but partly this is caused by our
current slightly clumsy classes/templates), things work out quite nicely and it
cleans up some confusion, e.g. a table entry is not an iterator etc.
Everything compiles into very efficient code, e.g. the loop condition 'it !=
accessor_table.end()' compiles into a single 'testl' instruction on ia32.
+1 for using standard APIs!
Review URL: https://chromiumcodereview.appspot.com/9691040
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a preparatory step for using the HashMap clas with Literal keys in the
full code generator. It removes some duplicated code already and removes the
need for 2 HashMaps at each use, which was overly complicated.
Removed one dead function on the way.
Review URL: https://chromiumcodereview.appspot.com/9639011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10973 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All module expressions, and all variables that might refer to modules,
are assigned interfaces (module types) that are resolved using
unification. This is necessary to deal with the highly recursive
nature of ES6 modules, which does not allow any kind of bottom-up
strategy for resolving module names and paths.
Error messages are rudimental right now. Probably need to track
more information to make them nicer.
R=svenpanne@chromium.org
BUG=v8:1569
TEST=
Review URL: https://chromiumcodereview.appspot.com/9615009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only JSObject enumerables with enum cache (fast case properties, no interceptors, no enumerable properties on the prototype) are supported.
HLoadKeyedGeneric with keys produced by for-in enumeration are recognized and rewritten into direct property load by index. For this enum-cache was extended to store property indices in a separate array (see handles.cc).
New hydrogen instructions:
- HForInPrepareMap: checks for-in fast case preconditions and returns map that contains enum-cache;
- HForInCacheArray: extracts enum-cache array from the map;
- HCheckMapValue: map check with HValue map instead of immediate;
- HLoadFieldByIndex: load fast property by it's index, positive indexes denote in-object properties, negative - out of object properties;
Changed hydrogen instructions:
- HLoadKeyedFastElement: added hole check suppression for loads from internal FixedArrays that are knows to have no holes inside.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9425045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change enables optimization of top-level and eval-code. For this to work, it adds
support for declaring global variables in optimized code.
At the same time it disables the eager generation of deoptimization support data
in the full code generator (originally introduced in
r10040). This speeds up initial compilation and saves
memory for functions that won't be optimized. It requires
recompiling the function with deoptimization
support when we decide to optimize it.
Review URL: https://chromiumcodereview.appspot.com/9187005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10700 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The ES.next draft rev 4 in section 11.13 reads:
It is a Syntax Error if the AssignmentExpression is contained in extended code
and the LeftHandSideExpression is an Identifier that does not statically resolve
to a declarative environment record binding or if the resolved binding is an
immutable binding.
This CL adds corresponding static checks for the immutable binding case.
TEST=mjsunit/harmony/block-const-assign
Review URL: http://codereview.chromium.org/8688007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10156 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
source code positions it gets from the program counter to recreate the scope
chain by reparsing the function or program.
This CL includes the following changes
* Adds source code positions for the assignment added by the rewriter.
* Run the preparser over global code first.
* Use the ScopeType from the ScopeInfo to determine if the code being debugged
is eval, function or global code instead of looking up the '.result' symbol.
TEST=mjsunit/debug-stepout-scope.js
Review URL: http://codereview.chromium.org/8590027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Original commit message:
Add a level of indirection to exception handler addresses.
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8538011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org,fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8462010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9975 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Remove a couple of unused fields from the FunctionLiteral, ensure that all
the bools are packed.
* Rename SaveScope and LexicalScope in the parser.
* Use an enum to generate the numbers 0..N and the dependent count, rather
than static const ints. This is simpler to extend (coming in a future
change).
R=danno@chromium.org,keuchel@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8505012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9933 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This was pretty heavyweight. It was kept in just for a few corner cases
that assumed it was there. We can work around them by making sure that the
expression in a reified test context is always really the expression that
was visited in that context; and by inspecting the context manually and
consing up a pair of extra AST IDs for the unusual case of unary not in a
value AST context.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8386037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9863 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements block scoped 'const' declared variables in harmony mode. They
have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing
uninitialized 'const' bindings in throws a ReferenceError.
As for 'let' bindings, the semantics of 'const' bindings in global scope is not
correctly implemented yet. Furthermore assignments to 'const's are silently
ignored. Another CL will introduce treatment of those assignments as early
errors.
Review URL: http://codereview.chromium.org/7992005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This also includes the two fixes from r9674 and r9675. Here's the diff
to the previous CL.
--- a/src/runtime.cc
+++ b/src/runtime.cc
@@ -11133,17 +11133,26 @@ class ScopeIterator {
context_(Context::cast(frame->context())),
nested_scope_chain_(4) {
+ // Catch the case when the debugger stops in an internal function.
+ Handle<SharedFunctionInfo> shared_info(function_->shared());
+ if (shared_info->script() == isolate->heap()->undefined_value()) {
+ if (shared_info->scope_info()->HasContext()) Next();
+ return;
+ }
+
// Check whether we are in global code or function code. If there is a stack
// slot for .result then this function has been created for evaluating
// global code and it is not a real function.
// Checking for the existence of .result seems fragile, but the scope info
// saved with the code object does not otherwise have that information.
- int index = function_->shared()->scope_info()->
+ int index = shared_info->scope_info()->
StackSlotIndex(isolate_->heap()->result_symbol());
// Reparse the code and analyze the scopes.
ZoneScope zone_scope(isolate, DELETE_ON_EXIT);
- Handle<SharedFunctionInfo> shared_info(function_->shared());
Handle<Script> script(Script::cast(shared_info->script()));
Scope* scope;
if (index >= 0) {
Review URL: http://codereview.chromium.org/8344046
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This eliminates compile-errors when assigning Handle<SerializedScopeInfo> to
Handle<Object> in a place where the declaration was not available because
variables.h was not included.
As a result I had to also move the enum Variable::Mode to v8globals.h and
rename it to VariableMode.
Review URL: http://codereview.chromium.org/8221004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Although this patch is not small, most parts of it are rather mechanical:
* First of all, the concept of a 'nil-like' value is introduced, which can be
null or undefined. They are treated symmetrically regarding comparisons, so
it makes sense to handle them in a uniform manner. It is a mystery why
JavaScript defines two of those beasts, when even *one* is a design wart...
* Extended and renamed a few things which now handle undefined in addition to
null.
* Made the parts of the full code generator and the hydrogen generation which
deal with comparisons a bit more similar regarding their handling of special
cases.
* Refactored the syntactical detection of special cases for comparisons,
hopefully making them a bit more readable and less copy-n-paste-oriented.
Things like this should really be a one-liner in any sane programming
language... :-P
* Cut down the length of the argument lists of a few functions to something
less insane, making them more easily understandable locally. This involves
minor code duplication, but this was a good tradeoff and can be remedied
later if necessary.
* Replaced some boolean arguments with more readable enums.
* Fixed a TODO: Values which are definitely a Smi or unboxed can never be equal
to null or undefined.
Review URL: http://codereview.chromium.org/7918012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9323 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The Great Master Plan is to move the recognition of special cases for
comparisons further down the compilation pipeline where more information is
available. This is a first step into this direction: The special handling of
equality comparisons involving null is pushed from the parser to the code
generators, removing the need for a special AST node. (There are rumors from
usually well-informed sources that this node type is actually a relic of ancient
crankshaft days...)
The next steps will be the unification of null/undefined handling and pushing
the special case handling in crankshaft even further down the pipeline, enabling
the recognition of cases like "var foo=null; if (foo === bar) ...", but these
will be in separate CLs.
Review URL: http://codereview.chromium.org/7887037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9293 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We have to emit code for declarations later into the body block
(and not into the start block) so that the environment contains
the correct values.
In order to capture the environment effect of the declarations
that generate code (function declarations) I inserted a separate
AST id and a HSimulate after the declarations are visited.
Also fixes handling deopt in named function expressions:
BUG=v8:1647
TEST=test/mjsunit/regress/regress-fundecl.js, test/mjsunit/regress/regress-1647.js
Review URL: http://codereview.chromium.org/7776009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9083 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Some AST nodes (Property, Call, etc.) store either a list of receiver
types or a monomorphic receiver type. This patch merges the two fields
using a small pointer list. GetMonomorphicReceiverType() is now a
purely convenience function returning the first and only recorded
type.
This saves about 500K (of about 39M) on average when compiling V8
benchmark as measured by a simple patch adding a zone allocation
counter (https://gist.github.com/1149397).
R=kmillikin@chromium.org
Review URL: http://codereview.chromium.org/7655017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8993 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove the try/finally used for with and catch. Instead of using
try/finally to handle break and continue from with or catch,
statically track nesting dept and clean up when compiling break or
continue.
And instead of using try/finally to handle throw to handler in a frame
whose pc is inside a with or catch, store the context that the handler
should run in in the handler itself.
BUG=
TEST=
Review URL: http://codereview.chromium.org/7618007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8922 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debugger can be entered from the deferred stack check in optimized code. This can cause both lazy deoptimization and debugger deoptimization (setting the first break point and inspecting the stack for optimized code respectively). This required deoptimization support from the deferred stack check.
The lazy deoptimiztion call is inserted when the deferred code is done including restoring the registers. The bailout to the full code is the begining of the loop body as that is where the stack check is sitting in the optimized code. The bailout is not to the stack check in the full code as that is sitting at the end of the loop.
R=kmillikin@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//7212025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8535 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The catch variable is bound in the catch scope. For simplicity in this
initial implementation, it is always allocated even if unused and always
allocated to a catch context even if it doesn't escape. The presence of
catch is no longer treated as a with.
In this change, care must be taken to distinguish between the scope where a
var declaration is hoisted to and the scope where the initialization occurs.
R=ager@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7280012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8496 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
