Skip to content

V
V8
Switch branch/tag
  1. 03 May, 2018 1 commit
  3. 25 Apr, 2018 1 commit
  5. 27 Jun, 2017 1 commit
  7. 19 Apr, 2017 1 commit
    • Caitlin Potter's avatar
      [parser] avoid complex for-loop desugaring when possible · 267115da
      Caitlin Potter authored 
      let/const declarations in "standard" C-style for-loops have
some complex desugaring to accommodate the case where loop
loop variables may be captured. This slows down the baseline
performance of for-loops with let variables.

This change attempts to avoid this desugaring if it's known that
the loop variable is not captured at any point. A side effect of
this change is that let/const loop variables, when not captured
within the loop body, are not necessarily shown in the debugger,
similar to other stack-allocated vars.

BUG=v8:4762, v8:5460
R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org

Change-Id: I8dbe545a12c086f675972bdba60c94998268311a
Reviewed-on: https://chromium-review.googlesource.com/472247
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44731}
      267115da
  9. 14 Dec, 2016 1 commit
  11. 29 Nov, 2016 3 commits
  13. 28 Nov, 2016 1 commit
  15. 27 Sep, 2016 1 commit
  17. 26 Sep, 2016 2 commits
  19. 16 Sep, 2016 1 commit
  21. 27 Apr, 2016 1 commit
  23. 22 Apr, 2016 1 commit
  25. 15 Mar, 2016 1 commit
    • adamk's avatar
      Remove Scope::scope_contains_with_ bit · 108efd7f
      adamk authored 
      This part of Scope has existed since V8's initial check in, but from what
I can tell it's not required to implement "with". The only tests that
depend upon it are tests of the debugger and the Scope mirrors, but the
resulting test behavior after removing the bit still seems perfectly
reasonable to me. In fact, with the included fix for scope name collection,
the scope mirror is actually improved with this change.

As a bi-product, this fixes the attached bug, about the contains_with
bit having inconsistent values in some arrow function compilation
scenarios.

BUG=chromium:592353
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

Cr-Commit-Position: refs/heads/master@{#34802}
      108efd7f
  27. 02 Mar, 2016 1 commit
  29. 30 Sep, 2015 1 commit
  31. 15 Jun, 2015 1 commit
  33. 19 May, 2015 2 commits
  35. 18 May, 2015 1 commit
  37. 13 May, 2015 1 commit
  39. 11 May, 2015 1 commit
  41. 07 May, 2015 1 commit
    • machenbach's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 5cab6be8
      machenbach authored 
      Revert of Resolve references to "this" the same way as normal variables (patchset #2 id:20001 of https://codereview.chromium.org/1130733003/)

Reason for revert:
[Sheriff] Breaks jetstream benchmark with errors like this:

>>> Running suite: JetStream/bigfib.cpp
>>> Stdout (#1):
undefined:93: ReferenceError: this is not defined
  this['Module'] = Module;
  ^
ReferenceError: this is not defined
    at eval (eval at __run (runner.js:13:3), <anonymous>:93:3)
    at eval (native)
    at __run (runner.js:13:3)
    at Object.runSimpleBenchmark (runner.js:44:31)
    at runner.js:97:13

Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=v8:2700
> LOG=N
>
> Committed: https://crrev.com/06a792b7cc2db33ffce7244c044a9c05afbb6116
> Cr-Commit-Position: refs/heads/master@{#28263}

TBR=rossberg@chromium.org,arv@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2700

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

Cr-Commit-Position: refs/heads/master@{#28283}
      5cab6be8
  43. 06 May, 2015 1 commit
    • wingo's avatar
      Resolve references to "this" the same way as normal variables · 06a792b7
      wingo authored 
      Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.

Based on work by Adrian Perez de Castro <aperez@igalia.com>.

BUG=v8:2700
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28263}
      06a792b7
  45. 05 May, 2015 2 commits
    • wingo's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 1e4173d9
      wingo authored 
      Revert of Resolve references to "this" the same way as normal variables (patchset #11 id:240001 of https://codereview.chromium.org/1097283003/)

Reason for revert:
nosnap failures

Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=
> LOG=N
>
> Committed: https://crrev.com/18619d355192e2699203d12d9ebb9caea107b693
> Cr-Commit-Position: refs/heads/master@{#28236}

TBR=rossberg@chromium.org,mstarzinger@chromium.org,dslomov@chromium.org,adamk@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28238}
      1e4173d9
    • wingo's avatar
      Resolve references to "this" the same way as normal variables · 18619d35
      wingo authored 
      Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.

Based on work by Adrian Perez de Castro <aperez@igalia.com>.

BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28236}
      18619d35
  47. 22 Apr, 2015 1 commit
  49. 09 Mar, 2015 1 commit
  51. 17 Nov, 2014 1 commit
    • dslomov's avatar
      harmony-scoping: Implement debugger support for script scope. · d7e3697d
      dslomov authored 
      We add a new ScopeType, ScopeType.Script. The scope with
ScopeType.Script is always present in the scope chain (ScopeIterator
fakes it if neededi - i.e. if ScriptContext for a script has not been
allocated since that script has no lexical declarations).
ScriptScope reflects ScriptContextTable.

R=yurys@chromium.org,yangguo@chromium.org
BUG=v8:3690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#25383}
      d7e3697d
  53. 22 Aug, 2014 1 commit
  55. 23 Apr, 2014 1 commit
  57. 21 Mar, 2014 1 commit
  59. 07 Mar, 2014 1 commit
  61. 24 Nov, 2011 1 commit
    • 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
  63. 21 Oct, 2011 1 commit
    • keuchel@chromium.org's avatar
      Reapply r9673 "Scope tree serialization and ScopeIterator cleanup." · 666c4be2
      keuchel@chromium.org authored 
      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
      666c4be2
  65. 19 Oct, 2011 1 commit
  67. 18 Oct, 2011 1 commit
  69. 14 Sep, 2011 1 commit