Skip to content

V
V8
Switch branch/tag
  1. 01 Feb, 2016 1 commit
    • yangguo's avatar
      [debugger] correctly find function context. · 835b0383
      yangguo authored 
      In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.

R=rossberg@chromium.org
BUG=chromium:582051
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33627}
      835b0383
  3. 19 Jan, 2016 1 commit
  5. 10 Dec, 2015 1 commit
  7. 30 Nov, 2015 2 commits
  9. 27 Nov, 2015 3 commits
  11. 26 Nov, 2015 1 commit
  13. 06 Nov, 2015 1 commit
  15. 02 Nov, 2015 2 commits
  17. 12 Oct, 2015 1 commit
    • littledan's avatar
      Test for var declarations in eval which conflict with let · d515e513
      littledan authored 
      Previously, name conflicts between var and let declarations were only
made into exceptions if they were visible at parse-time. This patch adds
runtime checks so that sloppy-mode direct eval can't introduce conflicting
var declarations. The change is implemented by traversing the scope chain
when a direct eval introduces a var declaration to look for conflicting
let declarations, up to the function boundary.

BUG=v8:4454
R=adamk
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#31211}
      d515e513
  19. 10 Sep, 2015 1 commit
  21. 01 Sep, 2015 2 commits
  23. 27 Aug, 2015 1 commit
  25. 26 Aug, 2015 1 commit
  27. 21 Aug, 2015 1 commit
    • rossberg's avatar
      [es6] Parameter scopes for sloppy eval · 365fd7bc
      rossberg authored 
      This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,

  let x = 1;
  function f(g = () => x) {
    var y
    eval("var x = 2")
    return g() + x  // f() = 3
  }

we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:

- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.

- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).

- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.

- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.

- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.

- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.

- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.

- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.

- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.

- While at it, refactor and unify some respective code in the debugger.

Sorry, this CL is large. I could try to split it up, but everything is rather entangled.

@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.

R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#30295}
      365fd7bc
  29. 14 Aug, 2015 1 commit
  31. 13 Aug, 2015 1 commit
  33. 07 Aug, 2015 1 commit
  35. 05 Aug, 2015 1 commit
  37. 31 Jul, 2015 1 commit
  39. 28 Jul, 2015 1 commit
  41. 23 Jul, 2015 1 commit
  43. 06 Jul, 2015 1 commit
  45. 01 Jul, 2015 1 commit
  47. 01 Jun, 2015 1 commit
  49. 29 May, 2015 1 commit
  51. 27 May, 2015 1 commit
  53. 19 May, 2015 2 commits
  55. 18 May, 2015 1 commit
  57. 13 May, 2015 1 commit
  59. 11 May, 2015 1 commit
  61. 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
  63. 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
  65. 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