Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 10 Sep, 2015 1 commit
  5. 01 Sep, 2015 2 commits
  7. 27 Aug, 2015 1 commit
  9. 26 Aug, 2015 1 commit
  11. 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
  13. 14 Aug, 2015 1 commit
  15. 13 Aug, 2015 1 commit
  17. 07 Aug, 2015 1 commit
  19. 05 Aug, 2015 1 commit
  21. 31 Jul, 2015 1 commit
  23. 28 Jul, 2015 1 commit
  25. 23 Jul, 2015 1 commit
  27. 06 Jul, 2015 1 commit
  29. 01 Jul, 2015 1 commit
  31. 01 Jun, 2015 1 commit
  33. 29 May, 2015 1 commit
  35. 27 May, 2015 1 commit
  37. 19 May, 2015 2 commits
  39. 18 May, 2015 1 commit
  41. 13 May, 2015 1 commit
  43. 11 May, 2015 1 commit
  45. 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
  47. 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
  49. 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
  51. 31 Mar, 2015 1 commit
  53. 13 Mar, 2015 1 commit
  55. 02 Mar, 2015 2 commits
  57. 26 Feb, 2015 1 commit
    • adamk's avatar
      Re-introduce ImportDeclaration to the parser · fa293dd7
      adamk authored 
      This also adds a new VariableMode, IMPORT, which will be
used to do appropriate binding for Import-declared Variables.

Only named imports are handled for now. "import *" and default
import syntaxes have had their TODOs adjusted to match the new
code structure.

BUG=v8:1569
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#26895}
      fa293dd7
  59. 17 Feb, 2015 1 commit
  61. 16 Dec, 2014 1 commit
  63. 13 Nov, 2014 1 commit
  65. 12 Nov, 2014 2 commits
  67. 07 Nov, 2014 1 commit
    • dslomov@chromium.org's avatar
      harmony_scoping: Implement lexical bindings at top level · 1a64b02d
      dslomov@chromium.org authored 
      This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.

When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable

Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.

R=adamk@chromium.org, rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1a64b02d
  69. 29 Oct, 2014 1 commit