- 11 Jul, 2012 1 commit
-
-
yangguo@chromium.org authored
R=jkummerow@chromium.org BUG=v8:2210 TEST=test-parsing/ParserSync Review URL: https://chromiumcodereview.appspot.com/10701116 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12036 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Apr, 2012 1 commit
-
-
svenpanne@chromium.org authored
BUG=v8:2109 TBR=jkummerow@chromium.org Review URL: https://chromiumcodereview.appspot.com/10270007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Mar, 2012 1 commit
-
-
erik.corry@gmail.com authored
Review URL: https://chromiumcodereview.appspot.com/9600009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11007 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 29 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 25 Nov, 2011 1 commit
-
-
lrn@chromium.org authored
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
-
- 24 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 01 Nov, 2011 1 commit
-
-
lrn@chromium.org authored
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
-
- 27 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/8396040 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9818 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 17 Oct, 2011 3 commits
-
-
lrn@chromium.org authored
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
-
keuchel@chromium.org authored
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
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/8306025 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9657 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Oct, 2011 1 commit
-
-
rossberg@chromium.org authored
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
-
- 22 Sep, 2011 1 commit
-
-
keuchel@chromium.org authored
TEST=preparser/strict-identifiers.pyt Review URL: http://codereview.chromium.org/7987002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9404 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Sep, 2011 1 commit
-
-
keuchel@chromium.org authored
The preparser has been out of sync with the parser. As a reminder, we have the following grammer for harmony mode Block :: { SourceElement* } SourceElement :: Statement FunctionDeclaration LetDeclaration instead of Block :: { Statement* } SourceElement :: Statement FunctionDeclaration The extension to allow FunctionDeclarations in statement positions in non-strict code is still active. Review URL: http://codereview.chromium.org/7983006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9363 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Sep, 2011 2 commits
-
-
lrn@chromium.org authored
Small cleanups in preparser. TEST=cctest/test-utils/SequenceCollectorRegression Review URL: http://codereview.chromium.org/7754014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9197 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
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
-
- 07 Sep, 2011 1 commit
-
-
lrn@chromium.org authored
Duplicate identifier detection must be an early syntax error in strict code, so errors in otherwise lazily compiled functions must be caught in the preparser. Originally introduced in r8541 and reverted in r8542. Now really compiles on Windows. Review URL: http://codereview.chromium.org/7782023 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9172 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 12 Aug, 2011 1 commit
-
-
mikhail.naganov@gmail.com authored
These files already include v8.h so they don't need to define the namespace alias again. Signed-off-by:
Thiago Farina <tfarina@chromium.org> Review URL: http://codereview.chromium.org/7640012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Jul, 2011 2 commits
-
-
lrn@chromium.org authored
Doesn't work on Windows yet. Crashes some layout-tests. Review URL: http://codereview.chromium.org/7278039 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8542 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
This is a fix and reapply of r8516 with some comments addressed and more tests added. The difference from r8516 is that canonicalization of number literals is no performed using the same methods as in v8, to avoid false positives/negatives when detecting duplicates. Review URL: http://codereview.chromium.org/7193045 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8541 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Jul, 2011 1 commit
-
-
lrn@chromium.org authored
Review URL: http://codereview.chromium.org/7308004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8534 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Jul, 2011 2 commits
-
-
lrn@chromium.org authored
Revision 8516 contained a temporary hack that doesn't work on Windows. TBR: ricow Review URL: http://codereview.chromium.org/7298008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
Add tests for duplicate properties of object initialisers to preparser. TEST=preparser Review URL: http://codereview.chromium.org/7168016 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8517 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Jun, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 21 Jun, 2011 1 commit
-
-
lrn@chromium.org authored
A multi-line comment containing a newline is considered a line-terminator for other purposes, but a "-->" following such a comment is considered as being on the same line as the text preceeding the multi-line comment. This behavior matches JSC matching Firefox. TEST=cctest/test-parsing/ScanHTMLEndComments Review URL: http://codereview.chromium.org/7218009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8351 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2011 1 commit
-
-
lrn@chromium.org authored
We now only recognize "native function" when it occurs in extension scripts (parsing with a non-NULL extension), and only if there is no line-terminator between "native" and "function" (so that it would otherwise be a Syntax Error). Preparsing never recognizes native functions, which is acceptable since we never preparse extension scripts (because we don't allow lazy functions anyway). BUG=v8:1097 Review URL: http://codereview.chromium.org/7206020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jun, 2011 1 commit
-
-
ager@chromium.org authored
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
-
- 24 May, 2011 1 commit
-
-
lrn@chromium.org authored
Small fixes. Added test for const declaration in strict mode. TEST=preparser/strict-function-statement Review URL: http://codereview.chromium.org/6990056 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8041 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 May, 2011 1 commit
-
-
lrn@chromium.org authored
This makes it possible to get total coverage without creating thousands of individual test files. Review URL: http://codereview.chromium.org/7061008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7985 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 May, 2011 2 commits
-
-
lrn@chromium.org authored
Make builder happy. Review URL: http://codereview.chromium.org/7046004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7954 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
Now tests for use of eval, arguments, reserved words and with statement. Review URL: http://codereview.chromium.org/7037024 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7951 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2011 1 commit
-
-
lrn@chromium.org authored
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
-
- 29 Mar, 2011 1 commit
-
-
lrn@chromium.org authored
It should now be possible to build the preparser using 'scons preparser' in both release and debug modes. Remove v8.h include from scanner-base.h and other files. Remove NativeAllocationChecker and all of its kind. Moved Isolate::PreallocatedStorage* to isolate.cc Review URL: http://codereview.chromium.org/6749029 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Mar, 2011 3 commits
-
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/6685088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Mar, 2011 1 commit
-
-
kmillikin@chromium.org authored
Function inlining no longer uses subgraphs. We detect inlining in an effect context and avoid materializing a return value earlier than we did before. Review URL: http://codereview.chromium.org/6635012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7080 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-