Skip to content

V
V8
Switch branch/tag
  1. 01 Sep, 2015 2 commits
  3. 31 Aug, 2015 3 commits
  5. 28 Aug, 2015 3 commits
    • yangguo's avatar
      Native context: do not put public symbols and flags on the js builtins object. · cde62571
      yangguo authored 
      R=cbruni@chromium.org,mlippautz@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30438}
      cde62571
    • bmeurer's avatar
      [es6] Implement spec compliant ToName (actually ToPropertyKey). · c403ede4
      bmeurer authored 
      This adds a %ToName runtime entry that uses the previously introduced
Object::ToName, which is based on the new Object::ToPrimitive method.
Also removes the need to expose ToName in various way via the builtins
and/or context.

Drive-by-fix: Let %HasProperty do the ToName conversion implicitly as
required.

BUG=v8:4307
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#30435}
      c403ede4
    • bmeurer's avatar
      [es6] Implement spec compliant ToPrimitive in the runtime. · f6c6d713
      bmeurer authored 
      This is the first step towards a spec compliant ToPrimitive
implementation (and therefore spec compliant ToNumber, ToString,
ToName, and friends).  It adds support for the @@toPrimitive
symbol that was introduced with ES2015, and also adds the new
Symbol.prototype[@@toPrimitive] and Date.prototype[@@toPrimitive]
initial properties.

There are now runtime functions for %ToPrimitive, %ToNumber and
%ToString, which do the right thing and should be used as fallbacks
instead of the hairy runtime.js implementations.  I will do the
same for the other conversion operations mentioned by the spec in
follow up CLs.  Once everything is in place we can look into
optimizing things further, so that we don't always call into the
runtime.

Also fixed Date.prototype.toJSON to be spec compliant.

R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#30434}
      f6c6d713
  7. 24 Aug, 2015 1 commit
  9. 21 Aug, 2015 4 commits
    • 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
    • yangguo's avatar
      Do not use js builtins object to determine whether a function is a builtin. · 371ad73a
      yangguo authored 
      We can use the script type to determine that instead. Script of type
TYPE_NATIVE are considered builtins, TYPE_NORMAL are not. The only exception
to this rule is the empty function, for which the script is TYPE_NATIVE
(observable by the debugger), but should be stringified to "function () {}"
instead of "function () { [native code] }". For this, I introduce a
hide_source flag on the script object.

We also use IsBuiltin and IsSubjectToDebugging interchangeably. For debugger,
we now use the latter, hiding the detail that only non-builtins are debuggable.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30285}
      371ad73a
    • yangguo's avatar
      Introduce SharedFunctionInfo::Iterator and Script::Iterator. · 4c5efa99
      yangguo authored 
      R=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30283}
      4c5efa99
    • yangguo's avatar
      Unify symbols sharing across native scripts and runtime. · eaba98d9
      yangguo authored 
      We currently have several ways to share symbols that are used in
both native scripts and the runtime. This change unifies this.
We do not use the symbols registry since we don't need the
registry any longer after bootstrapping, but the registry stays
alive afterwards.

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

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

Cr-Commit-Position: refs/heads/master@{#30280}
      eaba98d9
  11. 20 Aug, 2015 1 commit
  13. 19 Aug, 2015 2 commits
  15. 14 Aug, 2015 2 commits
  17. 13 Aug, 2015 5 commits
  19. 12 Aug, 2015 5 commits
  21. 11 Aug, 2015 2 commits
  23. 05 Aug, 2015 1 commit
  25. 04 Aug, 2015 1 commit
  27. 31 Jul, 2015 1 commit