The long-term goal is to move all recursive descent functions from Parser and
PreParser into ParserBase, but first they need to be unified.
Notes:
- The functions moved in this CL: ParseIdentifier, ParseIdentifierName,
ParseIdentifierNameOrGetOrSet, ParseIdentifierOrStrictReservedWord.
- IOW, this CL removes Parser::ParseIdentifier and PreParser::ParseIdentifier
and adds ParserBase::ParseIdentifier, etc.
- Error reporting used to require virtual funcs; now error reporting is moved to
the Traits too, and ParserBase no longer needs to be virtual.
- I had to move PreParser::Identifier out of the PreParser class, because
otherwise PreParserTraits cannot use it in a typedef.
BUG=v8:3126
LOG=N
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/149913006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.
Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.
In addition, add helper funcs for checking if an Expression is identifier or a
given identifier. (PreParser Expressions can do this.)
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/150103004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We used to have error messages which provide context, like "Variable name may
not be eval or arguments in strict mode", but for other illegal words we only
have non-context specific error messages like "Unexpected reserved word".
Providing the context makes the code unnecessarily complex, since every
individual place must remember to check for eval or arguments. This CL produces
a unified error message ("Unexpected eval or arguments in strict mode"), and puts
the error reporting to (Pre)Parser::ParseIdentifier.
Notes:
- The module feature is so experimental, that I decided to not allow "eval" or
"arguments" as module-related identifiers in the strict mode (even though this
check wasn't there before).
- Unfortunately, there were some inconsistencies, since it was the
responsibility of the caller of ParseIdentifier to check "eval" and "arguments"
and some places didn't have the check for no good reason. This CL is supposed to
keep backward compatibility and *not* introduce any new errors.
- ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax:
"LabelledStatement: Identifier : Statement", and no strict mode restrictions on
Identifier are listed.)
- Tests which compare error message strings will fail, and need to be updated.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/152813005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This contains the following fixes:
- We had strict_reserved_word and unexpected_strict_reserved, which one to use
was totally mixed in Parser and PreParser. Removed strict_reserved_word.
- When we saw a strict future reserved word when expecting something completely
different (such as "(" in "function foo interface"), Parser reports unexpected
identifier, whereas PreParser used to report unexpected strict reserved
word. Fixed PreParser to report unexpected identifier too.
- Unified parser and preparser error locations when the name of a function is a
strict reserved word. Now both point to the name.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/149253010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Made operator* return reference to the raw type, not pointer. New method 'get()' should be used when raw pointer is needed.
Also removed useless inline modifier from the SmaprtPointer methods and added const modifier to the methods that don't change smart pointer.
Made ~SmartPointerBase protected to avoid accidental calls of the non-virtual base class's destructor.
drive-by: fixed use after free in src/factory.cc
BUG=None
LOG=N
R=alph@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/101763003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Adds a notion of private symbols, mainly intended for internal use, especially, self-hosting of built-in types that would otherwise require new C++ classes.
On the JS side (i.e., in built-ins), private properties can be created and accessed through a set of macros:
NEW_PRIVATE(print_name)
HAS_PRIVATE(obj, sym)
GET_PRIVATE(obj, sym)
SET_PRIVATE(obj, sym, val)
DELETE_PRIVATE(obj, sym)
In the V8 API, they are accessible via a new class Private, and respective HasPrivate/Get/Private/SetPrivate/DeletePrivate methods on calss Object.
These APIs are designed and restricted such that their implementation can later be replaced by whatever ES7+ will officially provide.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/48923002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* AstNode now has a position info.
* Removed various ad-hoc position infos from subclasses (most of which had it).
* Position is always set with the constructor, instead of later.
* Take care to use kNoPosition in the right spots, to not crash the debugger.
Still to do:
* Eliminate Conditional::then/else_position and WhileStatement::condition_position.
* Make CaseClause a proper AstNode and eliminate its custom position.
* If possible, eliminate all uses of kNoPosition.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/24076007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17183 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Current v8 implementation may disable optimization for a particular function or block it with help of dont_optimize flag.
The patch propagates the reason of that to the SharedFunctionInfo where cpu profiler can get it.
SharedFunctionInfo is a heap object so I extracted 8 bits from OptsCount for handling bailout reason code.
BUG=none
TEST=test-profile-generator/BailoutReason
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/23817003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
The previous Windows issues have been resolved, and we now use GetTickCount64()
on Windows Vista and later, falling back to timeGetTime() with rollover
protection for earlier Windows versions.
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23490015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/23469013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23295034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When the regexp pattern parser encounters an unbound reference to a
capturing group, it needs to scan ahead to decide whether it really
is a reference. The scan advances to the end of the pattern string
and sets has_more_ to false, but fails to reset it to true so that
later on, parsing a character class wrongly fails.
R=ulan@chromium.org
BUG=v8:2690
Review URL: https://chromiumcodereview.appspot.com/15712006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14817 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
Replace the 'unable_to_parse' key used in three places with three difference keys.
Provide three more informative and less ambiguous error messages in place of 'Parse error'.
Add three test/message cases to cover the new messages.
BUG=2636
Review URL: https://codereview.chromium.org/14161007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14462 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
* 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/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 patch refactors the parser and preparser interface to be more
readable and type-safe. It has no behavior changes.
Previously, parsers and preparsers were configured via bitfield called
parser_flags in the Parser constructor, and flags in
PreParser::PreParseProgram, ParserApi::Parse, and ParserApi::PreParse.
This was error-prone in practice: six call sites passed incorrectly
typed values to this interface (a boolean FLAG value, a boolean false
and a boolean true value). None of these errors were caught by the
compiler because it's just an "int".
The parser flags interface was also awkward because it encoded a
language mode, but the language mode was only used to turn on harmony
scoping or not -- it wasn't used to actually set the parser's language
mode.
Fundamentally these errors came in because of the desire for a
procedural parser interface, in ParserApi. Because we need to be able
to configure the parser in various ways, the flags argument got added;
but no one understood how to use the flags properly. Also they were
only used by constructors: callers packed bits, and the constructors
unpacked them into booleans on the parser or preparser.
The solution is to allow parser construction, configuration, and
invocation to be separated. This patch does that.
It passes the existing tests.
BUG=
Review URL: https://codereview.chromium.org/13450007
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/api.cc (ScriptData::PreCompile): Fix bogus use of bogus value for
preparsing flags by removing those arguments, which were always zero.
* src/parser.h
* src/parser.cc (ParserApi::PreParse): Remove extension and flags
arguments, both of which were either always 0 or incorrectly used.
* test/cctest/test-parsing.cc (RegressChromium62639, Regress928): Fix
more bogus uses of preparser api.
BUG=
Review URL: https://codereview.chromium.org/13496008
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14140 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
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
- 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
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
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
I also discovered that our treatment of const declarations is inconsistent
when inside a global eval under 'with' (i.e., when created by
DeclareContextSlots). That is,
var x;
eval("const x = 9")
and
var x;
eval("with({}) const x = 9")
differ (the former assigns 9, the latter throws). This appears to be an
oversight from earlier changes to our const semantics (the latter shouldn't
throw either). Fixing this is a separate issue, though (and one that doesn't
seem quite worthwhile).
R=mstarzinger@chromium.org
BUG=v8:1991,80591
TEST=
Review URL: https://chromiumcodereview.appspot.com/10067010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11333 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
According to ES5 10.4.2(3), eval calls of strict code always require
their own lexical and variable environment. For now we just add a new
scope when we parse the strict mode directive. The clean solution would
be to always have this sope present (even for global eval calls) and
adapt variable binding to cope with that.
R=rossberg@chromium.org
BUG=v8:1624
TEST=mjsunit/regress/regress-1624,test262/S10.4.2.1_A1
Review URL: https://chromiumcodereview.appspot.com/9703021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11057 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
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
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
This CL fixes the preparser to have the same liberal automatic semicolon
insertion behaviour as the parser. In the case of a return statement in
global code we throw a syntax error at runtime rather than an early error
due to compatibility with KJS. However that hack allowed the following
syntactically incorrect program in global code in the parser but not in
the preparser:
if (false) return else {}
while the slightly saner version with the obligatory semicolon
if (false) return; else {}
was disallowed in the parser, but the preparser allowed it. This CL also
fixes that issue.
BUG=v8:1856
TEST=cctest/test-parsing.cc
Review URL: http://codereview.chromium.org/8844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10201 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
The ES.next drafts require that source code that matches the productions for
let and const bindings outside the extended mode trigger early syntax
errors. This CL adapts the parser / preparser accordingly under the harmony
scoping flag.
Summary:
* Harmony scoping flag not set: Old semantics allowing const in classic mode
with function level scope. Const binding in strict mode and let bindings in
classic and strict mode trigger early syntax errors.
* Harmony scoping is set: Use new harmony const and let in
extended mode and old const in classic mode. This is to preserve
compatibility with current web pages that already use
non-standard implementations of const. An early syntax error is
thrown on const in strict mode and on let in classic and strict
mode.
This depends on:
http://codereview.chromium.org/8562002/
TEST=mjsunit/harmony/block-early-errors.js
Review URL: http://codereview.chromium.org/8564001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10079 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
So far the parser had its own harmony flag to disable the harmony scoping
feature when parsing native functions. With the introduction of the extended
language mode this becomes unnecessary because native functions will never enter
the extended mode. The parser can thus track FLAG_harmony_scoping and the
language mode of the current scope to see if harmony features are allowed. The
scanner and preparser have to keep their flag, because they can't use
FLAG_harmony_scoping as it is not available for the preparser-process
executable.
This depends on:
http://codereview.chromium.org/8417035/
Review URL: http://codereview.chromium.org/8562002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
