Skip to content

V
V8
Switch branch/tag
  1. 01 Dec, 2011 2 commits
  3. 30 Nov, 2011 11 commits
  5. 29 Nov, 2011 10 commits
  7. 28 Nov, 2011 6 commits
  9. 25 Nov, 2011 7 commits
  11. 24 Nov, 2011 4 commits
    • yangguo@chromium.org's avatar
      Catch non-string subject in RegExpExecStub. · 50e5aaa7
      yangguo@chromium.org authored 
      There is no test case to trigger any crash. This is only to guard against the case that the native function is called with unsafe arguments.

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10064 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      50e5aaa7
    • keuchel@chromium.org's avatar
      Make the parser track the language mode instead of keeping its own harmony flag. · cbf08248
      keuchel@chromium.org authored 
      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
      cbf08248
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      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
      1e9a7267
    • mstarzinger@chromium.org's avatar
      Implement crankshaft support for nested object literals. · 7e7d4dfd
      mstarzinger@chromium.org authored 
      This generates optimized code for deep-copying of nested object literal
boilerplates which are statically known. Most of the boilerplates have
already been generated at crankshaft time, so this optimization should
kick in for virtually every object literal. Only nested object literal
graphs up to a certain depth and containing up to a certain total number
of properties are considered for this optimization. This will prevent
explosion of code size due to large object literals (e.g. eval on JSON).
Improves splay performance because object literals are created often.

R=fschneider@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      7e7d4dfd