Commit Graph

209 Commits

Author SHA1 Message Date
rossberg@chromium.org
0d906a8bdb Zonify types in compiler frontend
Clean up some zone/isolate handling in AST and its visitors on the way.

(Based on https://codereview.chromium.org/103743004/)

R=jkummerow@chromium.org, titzer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/102563004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18719 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-01-21 16:22:52 +00:00
yangguo@chromium.org
2a4be7067c Refactor the compiling pipeline.
Goals:
 - easier to read, more suitable identifiers.
 - better distinction between compiling optimized/unoptimized code
 - compiler does not install code on the function.
 - easier to add features (e.g. caching optimized code for osr).
 - remove unnecessary code.

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/110203002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18409 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-12-23 14:30:35 +00:00
bmeurer@chromium.org
a1d339a389 Remove unused ParserMessage class.
R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/52093007

Patch from Adrian Perez de Castro <aperez@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17613 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-11-11 08:07:37 +00:00
mstarzinger@chromium.org
acac89008d Defer allocation of constant literal properties.
This moves building of constant properties and elements arrays for all
materialized literals into the compiler. The parser no longer allocates
while parsing ObjectLiteral and ArrayLiteral expressions.

R=ulan@chromium.org

Review URL: https://codereview.chromium.org/61873003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17557 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-11-07 12:08:37 +00:00
mstarzinger@chromium.org
bdc8c36ca0 Unify several checking methods between parser and pre-parser.
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/27206002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17207 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-15 08:32:58 +00:00
mstarzinger@chromium.org
caf2884222 Introduce ParserBase for common code between parser and pre-parser.
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/27182002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17202 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-14 16:46:51 +00:00
mstarzinger@chromium.org
00125f43f0 Remove deprecated v8::preparser namespace.
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/27174002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17192 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-14 13:07:20 +00:00
rossberg@chromium.org
19d716989e Unify handling of position info in AST, part 1
* 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
2013-10-14 09:24:58 +00:00
mstarzinger@chromium.org
63d8abb6c6 Unify and fix checkers for duplicate object literal properties.
R=ulan@chromium.org
TEST=preparser/duplicate-property,mjsunit/regress/regress-parse-object-literal

Review URL: https://codereview.chromium.org/26375004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17136 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-10 11:58:16 +00:00
mvstanton@chromium.org
fc95207750 Revert "Unify and fix checkers for duplicate object literal properties."
This reverts commit 12c68518bd2c74dc4e44d928c84c17f98ca63359.
(r17114)

R=mstarzinger@chromium.org
TBR=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/26732006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-10 08:45:19 +00:00
mstarzinger@chromium.org
067a266426 Unify and fix checkers for duplicate object literal properties.
R=ulan@chromium.org
TEST=preparser/duplicate-property

Review URL: https://codereview.chromium.org/25755002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17114 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-04 16:58:01 +00:00
mstarzinger@chromium.org
191bcf20cc Limit entry points into the parser API.
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/24104006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-01 09:27:03 +00:00
dcarney@chromium.org
3e76d8b870 remove Isolate::Current from most files starting with 'o' through 'r'
R=svenpanne@chromium.org
BUG=

Review URL: https://codereview.chromium.org/23757017

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16513 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-09-04 07:05:11 +00:00
rossberg@chromium.org
971df386b3 Fix scoping of function declarations in eval inside non-trivial local scope
R=mstarzinger@chromium.org
BUG=v8:2594

Review URL: https://codereview.chromium.org/22901010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16286 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-23 09:25:37 +00:00
rossberg@chromium.org
83d9e6e7ee Add support for explicit octal and binary integer literals
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.8.3

ES6 extends the numeric literals to support explicit support
for binary and octal literals using the following syntax:

  0b10101
  0o777

This is currently behind the flag, --harmony-numeric-literals

BUG=2783
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/19300002

Patch from Erik Arvidsson <arv@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15772 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-19 09:57:35 +00:00
bmeurer@chromium.org
49b9ef269b Remove useless ZoneScopes from Parser.
R=danno@chromium.org
BUG=

Review URL: https://codereview.chromium.org/17817003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-26 08:05:41 +00:00
svenpanne@chromium.org
6c879c8a30 Removed some useless/dead code regarding CompileTimeValues.
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/17580018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15300 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-24 14:26:32 +00:00
wingo@igalia.com
1fb2f4b358 For-of statements do not permit initializers.
R=rossberg@chromium.org
BUG=v8:2720

Review URL: https://codereview.chromium.org/16739008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15082 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-12 12:37:44 +00:00
wingo@igalia.com
b29a78fb02 Baseline for-of implementation
Add full-codegen support for the ES6 for-of iteration statement.

R=mstarzinger@chromium.org, rossberg@chromium.org
TEST=mjsunit/harmony/iteration-semantics
BUG=v8:2214

Review URL: https://codereview.chromium.org/15288011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15002 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-07 11:12:21 +00:00
wingo@igalia.com
cb0d146862 Add initial parser support for harmony iteration
This commit adds initial parser support for harmony iteration.
Specifically, it will parse:

  for (x of y) {}
  for (let x of y) {}
  for (var x of y) {}

The semantics are still unimplemented.

TEST=mjsunit/harmony/for-of-syntax
BUG=v8:2214
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/15300018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14984 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-06 14:38:26 +00:00
rossberg@chromium.org
919d64adce Add type field to AST expression nodes
More importantly, do a bunch of renamings of incidental existing "types" to avoid actual and potential name clashes (and also to improve consistency).

R=svenpanne@chromium.org
BUG=

Review URL: https://codereview.chromium.org/16549002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14978 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-06 13:28:22 +00:00
verwaest@chromium.org
5e8679beea Remove the optimized construct stub.
R=mstarzinger@chromium.org

Review URL: https://chromiumcodereview.appspot.com/15993016

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14946 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-05 08:43:25 +00:00
wingo@igalia.com
467b16fd3a Remove unneeded argument from Parser::GetSymbol
Parser::GetSymbol can't actually fail, so no need for the bool* ok
argument or the CHECK_OK in callers.

BUG=
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/15421007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14727 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-05-21 10:45:58 +00:00
verwaest@chromium.org
52008429b7 Use mutable heapnumbers to store doubles in fields.
R=danno@chromium.org

Review URL: https://chromiumcodereview.appspot.com/14850006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14597 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-05-08 15:02:08 +00:00
mstarzinger@chromium.org
591a8ec86c Calling a generator function returns a generator object
* src/heap.h:
* src/heap.cc:
* src/objects-debug.cc:
* src/objects-inl.h:
* src/objects-printer.cc:
* src/objects-visiting.cc:
* src/objects.cc:
* src/objects.h: Define a new object type, JSGeneratorObject.

* src/factory.h:
* src/factory.cc (NewFunctionFromSharedFunctionInfo): Generator function
  inital maps construct the new JS_GENERATOR_OBJECT_TYPE objects, not
  generic JSObjects.

* src/runtime.h:
* src/runtime.cc (Runtime_CreateJSGeneratorObject):
* src/arm/full-codegen-arm.cc (Generate):
* src/ia32/full-codegen-ia32.cc (Generate):
* src/x64/full-codegen-x64.cc (Generate): Before visiting generator
  bodies, arrange to construct and return a generator object.

* test/mjsunit/harmony/generators-objects.js: Add tests for the
  properties and prototype of generator objects.

BUG=v8:2355
TEST=mjsunit/harmony/generators-objects

Review URL: https://codereview.chromium.org/13542002

Patch from Andy Wingo <wingo@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14264 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-15 12:29:44 +00:00
mstarzinger@chromium.org
1345caa208 Devirtualize Parser
* src/parser.h: No one inherits from Parser, so the destructor can be
  non-virtual, removing the need for Parser to have a vtable. Also add
  BASE_EMBEDDED to it and to RegExpParser.

BUG=

Review URL: https://codereview.chromium.org/13640007
Patch from Andy Wingo <wingo@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-08 11:53:50 +00:00
mstarzinger@chromium.org
d71678676f Refactor parser mode configuration for correctness
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
2013-04-05 13:01:06 +00:00
mstarzinger@chromium.org
7e0ae6da66 Fix bogus uses of preparser API
* 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
2013-04-04 14:34:19 +00:00
mstarzinger@chromium.org
2816f19680 Add parser support for generators.
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
2013-04-02 17:34:59 +00:00
verwaest@chromium.org
37a2e32496 Unify kMaxArguments with number of bits used to encode it.
Increase the number of bits by 1 by making Flags unsigned.

BUG=chromium:211741

Review URL: https://chromiumcodereview.appspot.com/12886008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13964 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-03-18 13:35:17 +00:00
danno@chromium.org
5a40f006f9 Remove unused private member variables found by clang -Wunused-private-field
Review URL: https://codereview.chromium.org/11414207
Patch from Adam Klein <adamk@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-11-29 15:13:49 +00:00
rossberg@chromium.org
00132da734 Bump variable limit further to 2^17.
R=jkummerow@chromium.org
BUG=151625

Review URL: https://codereview.chromium.org/11099063

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12698 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-10-11 11:40:10 +00:00
rossberg@chromium.org
b07f38a46b Reject local module declarations.
R=mstarzinger@chromium.org
BUG=150628

Review URL: https://codereview.chromium.org/11033025

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-10-05 09:14:08 +00:00
rossberg@chromium.org
20b1c426cf Bump number of allowed variables per scope to 65535, to address GWT.
R=jkummerow@chromium.org
BUG=151625

Review URL: https://codereview.chromium.org/10965063

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12600 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-09-24 16:22:17 +00:00
rossberg@chromium.org
a6e45ce7b8 Introduce some predicates over variable modes.
These should be handy when we add more declaration forms for Harmony.

R=svenpanne@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/10897010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12404 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-08-29 09:19:53 +00:00
mstarzinger@chromium.org
fa2287fa96 Force eager compilation of parenthesized functions.
This makes the compiler use eager compilation for function literals that
are parenthesized. We consider this to be a hint that the function will
be called immediatly and hence try to avoid parsing it twice. The parser
already respects this heuristic.

R=ulan@chromium.org

Review URL: https://chromiumcodereview.appspot.com/10836132

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-08-07 14:47:36 +00:00
mstarzinger@chromium.org
6744e6e9a6 Remove obsolete ParserApi::PartialPreParse method.
R=yangguo@chromium.org

Review URL: https://chromiumcodereview.appspot.com/10787036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12103 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-07-17 11:31:05 +00:00
rossberg@chromium.org
ec042177d7 Incorporate constness into inferred interfaces
(in preparation for handling imports).

R=svenpanne@chromium.org
BUG=v8:1569
TEST=

Review URL: https://chromiumcodereview.appspot.com/10698167

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12078 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-07-13 09:29:43 +00:00
rossberg@chromium.org
98db1a369d Implement proper module linking.
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
2012-07-09 08:59:03 +00:00
sanjoy@chromium.org
6fef6e451c Unbreak bleeding_edge by getting the Parser to work with a CompilationInfo instead of a Handle<Script> and a Zone. This should have been fixed in the initial patch itself but escaped my attention.
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/10583031

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-20 10:56:53 +00:00
sanjoy@chromium.org
9e4fbb45c1 One Zone per CompilationInfo.
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
2012-06-20 08:58:41 +00:00
sanjoy@chromium.org
6125718f37 Remove TLS access for current Zone.
By passing around a Zone object explicitly we no longer need to do a
TLS access at the sites that allocate memory from the current Zone.

BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/10534006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-11 12:42:31 +00:00
sanjoy@chromium.org
98db16d94f Progress towards making Zones independent of Isolates and Threads.
This CL changes some parts of the code to explicitly pass around a
Zone.  Not passing in a zone is okay too (in fact most of v8 still
doesn't), but that may incur a TLS lookup.

BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/10443114

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-04 14:42:58 +00:00
mstarzinger@chromium.org
79a98de9f7 Fix declarations escaping global strict eval.
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
2012-03-15 13:02:21 +00:00
erik.corry@gmail.com
03cfc4363b Fix input and output to handle UTF16 surrogate pairs.
Review URL: https://chromiumcodereview.appspot.com/9600009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11007 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-12 12:35:28 +00:00
rossberg@chromium.org
448b620dad Basic interface inference for modules.
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
2012-03-08 13:03:07 +00:00
rossberg@chromium.org
b89c0a962c AST extensions and parsing for import & export declarations.
R=jkummerow@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9496003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-29 12:12:52 +00:00
rossberg@chromium.org
d809d17f5d Further refactoring of declarations in the AST:
Define modules as module declarations.
Separate function declarations from var declarations.

R=jkummerow@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9460064

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10854 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-28 10:12:39 +00:00
rossberg@chromium.org
958b3bf470 Parsing of basic module declarations (no imports/exports yet).
Module definitions are not compiled or otherwise executed yet.
Toplevel module identifiers are bound but never initialized.

R=kmillikin@chromium.org,mstarzinger@google.com
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9401008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10759 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-20 14:02:59 +00:00
rossberg@chromium.org
a0b287a3b1 Extend scanner with new Harmony module keywords (under flag).
R=mstarzinger@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9352013

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10638 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-08 10:53:58 +00:00
jkummerow@chromium.org
d795b7c620 Collect AstNode type information
Review URL: https://chromiumcodereview.appspot.com/9221011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10631 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-08 09:56:33 +00:00
erik.corry@gmail.com
70da367f6b More spelling changes.
Review URL: http://codereview.chromium.org/9231009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10407 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-16 12:38:59 +00:00
keuchel@chromium.org
08b4262512 Statically check for assignments to const in harmony mode.
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
2011-12-05 14:43:28 +00:00
keuchel@chromium.org
b3a2e242db Reapply "Fix the ScopeIterator reimplementation".
This reapplies a fixed version of r10076 that also works on arm. Patch set one is r10076 reapplied and patch set 2 contains the new fix.

Review URL: http://codereview.chromium.org/8725001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10080 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-29 08:43:14 +00:00
keuchel@chromium.org
9664e48e14 Revert r10076 due to arm build failures.
Review URL: http://codereview.chromium.org/8716005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10077 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-28 14:01:13 +00:00
keuchel@chromium.org
8866d63cc9 The ScopeIterator uses recorded scope position - as detailed in scopes.h - and
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
2011-11-28 12:47:39 +00:00
lrn@chromium.org
ebccde15bc Don't preparse large files to find boundaries of lazy functions.
Instead use the preparser inline to parse only the lazy function
bodies.

This is still disabled for small files.
More measurements are needed to determine if lazy-compiling small
sources is worth it.

Review URL: http://codereview.chromium.org/8662037

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10066 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-25 09:36:31 +00:00
keuchel@chromium.org
cbf08248f7 Make the parser track the language mode instead of keeping its own harmony flag.
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
2011-11-24 15:58:09 +00:00
keuchel@chromium.org
1e9a7267ab Introduce extended mode.
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
2011-11-24 15:17:04 +00:00
yangguo@chromium.org
6551e8d47d Removing exit time destructors by leaking static members.
Note that some cctests and d8 still contain statical members with exit time destructors.

BUG=v8:1828

Review URL: http://codereview.chromium.org/8586025

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10025 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-18 08:59:33 +00:00
keuchel@chromium.org
08c9629f80 Static resolution of outer variables in eval code.
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
2011-11-15 13:48:40 +00:00
kmillikin@chromium.org
e49d533b50 Reapply "Add a level of indirection to exception handler addresses."
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
2011-11-11 13:48:14 +00:00
kmillikin@chromium.org
66ff8828a0 Revert "Add a level of indirection to exception handler addresses."
This reverts r9975.  This change broke (at least) snapshots on x64.

TBR=fschneider@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/8540005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9976 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-11 13:13:35 +00:00
kmillikin@chromium.org
1635117db9 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,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
2011-11-11 12:51:42 +00:00
kmillikin@chromium.org
7664133e87 A small collection of cleanup in the parser and AST.
* 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
2011-11-09 13:54:26 +00:00
lrn@chromium.org
65b9ab93af Merged Scanner and JavaScriptScanner.
JavaScriptScanner had become the only concrete subclass of Scanner, so there
was no longer a need for the distinction.

Also fixed up comments.

Review URL: http://codereview.chromium.org/8384003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9854 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-01 07:47:15 +00:00
keuchel@chromium.org
a9a97d010e Remove kInvalidStrictFlag and make gcc-4.5 happy again.
Review URL: http://codereview.chromium.org/8403036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-28 09:10:29 +00:00
keuchel@chromium.org
6e767e3f2d Use StrictModeFlag in preparser and preparse data.
Review URL: http://codereview.chromium.org/8396040

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9818 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-27 13:08:51 +00:00
keuchel@chromium.org
e8bccc2cb0 Block scoped const variables.
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
2011-10-25 08:33:08 +00:00
keuchel@chromium.org
666c4be29f Reapply r9673 "Scope tree serialization and ScopeIterator cleanup."
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
2011-10-21 10:26:59 +00:00
keuchel@chromium.org
17cc6d313f Revert 9673, 9674 and 9675 because of failing webkit tests.
This reverts commits
r9673: "Scope tree serialization and ScopeIterator cleanup."
r9674: "Use OS::SNPrintF instead of snprintf."
r9675: "Use int instead of size_t, StrLength instead of strlen."

Review URL: http://codereview.chromium.org/8353003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9703 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-19 12:15:02 +00:00
keuchel@chromium.org
4e5643a648 Scope tree serialization and ScopeIterator cleanup.
The intention is to store enough scope information for the debugger to
handle stack allocation of block scoped variables introduced by
http://codereview.chromium.org/7860045/ .

This CL is based on
http://codereview.chromium.org/7904008/ .

Review URL: http://codereview.chromium.org/7979001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-18 08:46:46 +00:00
lrn@chromium.org
2bbf3bbee7 Make native syntax an early error in the preparser.
Previously the preparser always accepted natives syntax and let the
real parser throw the syntax error. In ES5, it should be an early error,
so the preparser must catch the error.
The perparser library does not expose parsing for natives syntax, it's
only used internally.

Review URL: http://codereview.chromium.org/8306024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9660 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-17 12:45:52 +00:00
keuchel@chromium.org
6f4e70a1dc Let bound iteration variables in for-loops
TEST=mjsunit/harmony/block-for.js

Review URL: http://codereview.chromium.org/7837028

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9658 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-17 12:19:06 +00:00
keuchel@chromium.org
0706a98b2a Introduce with scope and rework variable resolution.
Review URL: http://codereview.chromium.org/7904008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9650 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-17 09:29:37 +00:00
rossberg@chromium.org
1abf3ed0a4 Introduce collective --harmony flag.
Shorten --harmony-block-scoping to --harmony-scoping.

R=keuchel@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/8226017

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9589 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-12 12:23:06 +00:00
fschneider@chromium.org
876fa09feb Move declaration of SerializedScopeInfo from variables.h to objects.h
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
2011-10-11 08:41:19 +00:00
svenpanne@chromium.org
8c744768e2 Nuke CompareToNull AST node.
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
2011-09-15 09:09:40 +00:00
lrn@chromium.org
689f3cb314 Rename scanner.* to scanner-character-streams.*. and scanner-base.* to scanner.*
R=lrn@chromium.org

Signed-off-by: Thiago Farina <tfarina@chromium.org>

Review URL: http://codereview.chromium.org/7739020

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9195 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-08 13:06:44 +00:00
keuchel@chromium.org
d434d3158c Detect conflicting variable bindings in harmony mode.
BUG=
TEST=mjsunit/harmony/block-conflicts.js

Review URL: http://codereview.chromium.org/7756014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9102 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-01 12:31:18 +00:00
keuchel@chromium.org
c6c504f8b6 Parse harmony let declarations.
Implementation of the harmony block scoped let bindings as proposed here:
http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings

Changes to the syntax are explained there. They are active under the
harmony_block_scoping_ flag in the parser.

Review URL: http://codereview.chromium.org/7616009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-16 14:24:12 +00:00
kmillikin@chromium.org
91553bbacd Simplify handling of exits from with and catch.
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
2011-08-12 10:52:49 +00:00
keuchel@chromium.org
3c7ca304fe Preliminary code for block scopes and block contexts.
BUG=
TEST=

Review URL: http://codereview.chromium.org/7549008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-11 16:29:28 +00:00
kmillikin@chromium.org
7adb10a48e Fix a bug in named getter/setter compilation.
Because these are function literals that have an associated name, we were
compiling them as if they were named function expressions.  This is
incorrect, the property name should not be in scope.

R=vegorov@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/7599024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8863 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-09 12:43:08 +00:00
kmillikin@chromium.org
d941053dbe Revert "Revert "Fix a bug in scope analysis.""
Reapply r8838 with a fix for the issue of function names.

Because function names can be added/changed/removed through the API,
remember whether the function is anonymous when initially parsed and use
that information when compiling.

R=vegorov@chromium.org
BUG=1583
TEST=regress-1583

Review URL: http://codereview.chromium.org/7491097

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8858 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-08 16:14:46 +00:00
kmillikin@chromium.org
3e28347d55 Revert "Fix a bug in scope analysis."
This reverts commit revision 8838.

TBR=ricow@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/7584005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8839 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-05 09:20:08 +00:00
kmillikin@chromium.org
b625ce2b6b Fix a bug in scope analysis.
When recompiling code (e.g., when optimizing) we could incorrectly hoist
some function expressions.  This leads to incorrect results or a crash.  The
root cause was that functions were not correctly categorized as expression
or declaration at parse time.

This requires some extra hoops to prevent the print name "anonymous" for
functions created by 'new Function' from establishing a binding.

R=vegorov@chromium.org,kasperl@chromium.org
BUG=1583
TEST=regress-1583

Review URL: http://codereview.chromium.org/7572019

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8838 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-05 08:28:11 +00:00
vitalyr@chromium.org
bfd7c71954 Pass isolate to AST ID functions.
R=ager@chromium.org

Review URL: http://codereview.chromium.org/7399023

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8678 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-07-18 17:32:41 +00:00
vitalyr@chromium.org
3d323c691b Avoid TLS load in AstNode constructor.
R=ager@chromium.org

Review URL: http://codereview.chromium.org/7383013

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8664 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-07-15 16:57:35 +00:00
kmillikin@chromium.org
57c29c1f29 Fix a bug in with and catch context allocation.
We were only looking one level up the scope chain to decide which
closure to use in the fresh context.  Instead, we should look to the
first non-catch scope.

R=vegorov@chromium.org
BUG=1528
TEST=regress-1528

Review URL: http://codereview.chromium.org/7309002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8523 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-07-04 09:34:47 +00:00
kmillikin@chromium.org
f4c4df2d9a Introduce scopes to keep track of catch blocks at compile time.
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
2011-06-30 14:37:55 +00:00
keuchel@chromium.org
ab3d4cf7b8 Proper handling of future reserved words in strict and normal mode.
BUG=86442
TEST=mjsunit/keywords-and-reserved_words.js

Review URL: http://codereview.chromium.org/7207007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8421 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-24 14:59:51 +00:00
lrn@chromium.org
e378829b24 Combined identical classes V8JavaScriptScanner and StandAloneJavaScriptScanner.
Now only uses the common superclass of the two scanner classes.
Updated comment on KeywordMatcher.

Review URL: http://codereview.chromium.org/7211013

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8362 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-22 09:06:03 +00:00
ager@chromium.org
626cdffaef Fix Array.prototype.{reduce,reduceRight} to pass undefined as receiver for strict mode callbacks.
Propagate strict mode information from pre-parser to parser for lazily compiled functions.

R=lrn@chromium.org
BUG=v8:1436
TEST=mjsunit/regress/regress-1436.js

Review URL: http://codereview.chromium.org/7044054

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8227 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-09 09:05:15 +00:00
kmillikin@chromium.org
e9a1ffde92 Stop using with explicitly to implement try/catch.
The AST for TryCatch gives us enough structure that we do not need to expand
it to explicitly include a with.  Try/catch is still handled the same as
before at runtime.

R=ager@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/7134014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8224 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-08 13:55:33 +00:00
ricow@chromium.org
3c7e1d7015 Create stand-alone json parser (including scanner).
The current json parser and scanner inherits fromt he normal scanners and parsers,
which are more complicated than we need for parsing json.

The supplied scanner works directly on the string supplied and has a
fast case mode for scanning only ascii characters (it will simply
create a substring or a symbol directly from the existing string). To
allow for creating symbols from a substring I have added a
SubStringAsciiSymbolKey that creates the hash based from our string
without extracting the sub-string. In case we need to add the symbol
it simply creates the symbol directly from the characters inside the
given string.
Review URL: http://codereview.chromium.org/7039037

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8029 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-05-24 12:16:23 +00:00
sgjesse@chromium.org
230a56abda Limit the number of local variables in a function
Review URL: http://codereview.chromium.org//7003030

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7892 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-05-16 08:27:52 +00:00
sandholm@chromium.org
fcd9380eda JSON.parse improvement. Call "LookupSymbol" rather than "NewString"
for property string tokens.
Review URL: http://codereview.chromium.org/7004016

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7859 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-05-11 11:56:15 +00:00
lrn@chromium.org
1a169aa3f0 Strict mode detection in preparser.
Handle octal escapes in everything but RegExps.
Extend preparser test suite to test whether the preparser reports
exceptions to throw.

TEST=preparser/*

Review URL: http://codereview.chromium.org/6927075

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7804 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-05-06 11:41:15 +00:00
lrn@chromium.org
a932441a0c Cleanup of ScannerConstants, now named UnicodeCache.
The ScannerConstants class was originally static fields on the scanner class.
During creation of the stand-alone preparser and later isolates, it has been
moved into a separate class with a per-isolate instance.
It is used to hold caching unicode Predicate values.

This change renames the class to UnicodeCache, and passes a reference
to the instance down to methods that doesn't have an easy access to
an isolate (to avoid, e.g., having to do an Isolate::Current() for every
number parsed).

Review URL: http://codereview.chromium.org/6824071

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-04-12 08:27:38 +00:00