- The global object has a reference to the current global scope chain.
Running a script adds to the chain if it contains global lexical declarations.
- Scripts are executed relative to a global, not a native context.
- Harmony let and const bindings are allocated to the innermost global context;
var and function still live on the global object.
(Lexical bindings are not reflected on the global object at all,
but that will probably change later using accessors, as for modules.)
- Compilation of scripts now needs a (global) context (previously only eval did).
- The global scope chain represents one logical scope, so collision tests take
the chain into account.
R=svenpanne@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/10872084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 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
Do proper dispatch on declaration type instead of mingling together
different code generation paths. Once we add more declaration forms,
this is more scalable.
In separate steps, I'd like to (1) clean up the logic for DeclareGlobal,
and (2) try to reduce the special handling of the name function var if
possible.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9704054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11331 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
The old HashMap class had an explicit member to determine the allocation
policy. The template version matches the approach used already for
lists.
Cleanup some include dependencies and unnecessary forward declarations.
Cleanup some dead code from isolate.h and replace some HEAP macros
with GetHeap().
Review URL: https://chromiumcodereview.appspot.com/9372106
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10806 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Runtime_DebugEvaluate creates an empty context which is not correctly handled in FullCodeGenerator::ContextSlotOperandCheckExtensions because the corresponding scope indicates that it has no context.
BUG=crbug.com/107996
TEST=test/mjsunit/regress/regress-crbug-107996.js
Review URL: https://chromiumcodereview.appspot.com/9310027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10582 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For calls of the form ident(...) record position of the identifier as the position of the call. For other calls record positions of the opening parenthesis.
This guarantees that for expressions of the form function(){}() call position will not intersect with positions recorded for function literal which is used by the debugger for scope chain resolution.
R=kmillikin@chromium.org
BUG=http://crbug.com/109195
TEST=test/mjsunit/regress/regress-109195.js
Review URL: http://codereview.chromium.org/9125001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10350 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
So far free variables references in eval code are not statically
resolved. For example in
function foo() { var x = 1; eval("y = x"); }
the variable x will get mode DYNAMIC and y will get mode DYNAMIC_GLOBAL,
i.e. free variable references trigger dynamic lookups with a fast case
handling for global variables.
The CL introduces static resolution of free variables references in eval
code. If possible variable references are resolved to bindings belonging to
outer scopes of the eval call site.
This is achieved by deserializing the outer scope chain using
Scope::DeserializeScopeChain prior to parsing the eval code similar to lazy
parsing of functions. The existing code for variable resolution is used,
however resolution starts at the first outer unresolved scope instead of
always starting at the root of the scope tree.
This is a prerequisite for statically checking validity of assignments in
the extended code as specified by the current ES.next draft which will be
introduced by a subsequent CL. More specifically section 11.13 of revision 4
of the ES.next draft 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.
TEST=existing tests in mjsunit
Review URL: http://codereview.chromium.org/8508052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9999 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
After introduction of with scopes we have enough static information to omit
context allocation in the case that a variable is accessed from a nested block
or catch scope of the same function. Only variables accessed from the inside of
a nested function or with scope are forced to be allocated in the context.
This essentially reverts
http://code.google.com/p/v8/source/detail?r=9281 .
which in turn reverted an earlier change.
Review URL: http://codereview.chromium.org/8431001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9872 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
