Skip to content

V
V8
Switch branch/tag
  1. 24 Feb, 2017 1 commit
  3. 22 Feb, 2017 1 commit
  5. 20 Feb, 2017 2 commits
  7. 16 Feb, 2017 3 commits
    • jwolfe's avatar
      Implement new Function.prototype.toString --harmony-function-tostring · d1d4b9ce
      jwolfe authored 
      For functions declared in source code, the .toString() representation
will be an excerpt of the source code.
* For functions declared with the "function" keyword, the excerpt
  starts at the "function" or "async" keyword and ends at the final "}".
  The previous behavior would start the excerpt at the "(" of the
  parameter list, and prepend a canonical `"function " + name` or
  similar, which would discard comments and formatting surrounding the
  function's name. Anonymous functions declared as function expressions
  no longer get the name "anonymous" in their toString representation.
* For methods, the excerpt starts at the "get", "set", "*" (for
  generator methods), or property name, whichever comes first.
  Previously, the toString representation for methods would use a
  canonical prefix before the "(" of the parameter list. Note that any
  "static" keyword is omitted.
* For arrow functions and class declarations, the excerpt is unchanged.

For functions created with the Function, GeneratorFunction, or
AsyncFunction constructors:
* The string separating the parameter text and body text is now
  "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
* At one point, newline normalization was required by the spec here,
  but that was removed from the spec, and so this CL does not do it.

Included in this CL is a fix for CreateDynamicFunction parsing. ')'
and '`' characters in the parameter string are no longer disallowed,
and Function("a=function(", "}){") is no longer allowed.

BUG=v8:4958, v8:4230

Review-Url: https://codereview.chromium.org/2156303002
Cr-Commit-Position: refs/heads/master@{#43262}
      d1d4b9ce
    • Marja Hölttä's avatar
      [parser] No need to collect literal counts. · d21621cf
      Marja Hölttä authored 
      Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ )

BUG=

Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6
Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43238}
      d21621cf
    • neis's avatar
      [ast] Mark temporaries as maybe-assigned by default. · 503ad143
      neis authored 
      This is in order to prevent accidental bugs in desugarings.

R=adamk@chromium.org
BUG=v8:5636

Review-Url: https://codereview.chromium.org/2693313002
Cr-Commit-Position: refs/heads/master@{#43237}
      503ad143
  9. 15 Feb, 2017 2 commits
    • caitp's avatar
      [async-iteration] add support for for-await-of loops in Async Functions · 76ab55e3
      caitp authored 
      When --harmony-async-iteration is enabled, it is now possible to
use the for-await-of loop, which uses the Async Iteration protocol
rather than the ordinary ES6 Iteration protocol.

the Async-from-Sync Iterator object is not implemented in this CL,
and so for-await-of loops will abort execution if the iterated object
does not have a Symbol.asyncIterator() method. Async-from-Sync
Iterators are implemented seperately in https://codereview.chromium.org/2645313003/

BUG=v8:5855, v8:4483
R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/2637403008
Cr-Commit-Position: refs/heads/master@{#43224}
      76ab55e3
    • Marja Hölttä's avatar
      [parser] Minor refactoring: parameter handling · e7ebb930
      Marja Hölttä authored 
      - Different places used is_simple to mean different things; renamed one.

- No need to do Scope::SetHasNoSimpleParameters multiple times.

- Normally we create VAR parameters with a name, or (for destructuring
  parameters), TEMPORARY parmeters with an empty name. *Except* for
  destructuring rest parameters; then we create VAR a parameter with an empty
  name. This CL makes the empty-named parameter TEMPORARY instead of VAR.

- This makes it clear that Parser::DeclareFormalParameters declares exactly
  those params which Parser::BuildParamerterInitializationBlock doesn't declare.

- This unification doesn't change any functionality, but it makes sense to do
  since I'll need to make PreParser emulate what Parser does; this way I don't
  need to emulate the weird behavior.

BUG=v8:5501

Change-Id: Ifa6c116bc5908f4e03a36e74f47558888d1582bd
Reviewed-on: https://chromium-review.googlesource.com/443106Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43220}
      e7ebb930
  11. 13 Feb, 2017 1 commit
  13. 10 Feb, 2017 5 commits
  15. 09 Feb, 2017 1 commit
  17. 07 Feb, 2017 1 commit
  19. 06 Feb, 2017 2 commits
  21. 03 Feb, 2017 1 commit
  23. 01 Feb, 2017 1 commit
    • adamk's avatar
      [parser] Remove hoist_scope from DeclarationDescriptor · 59b8496c
      adamk authored 
      The hoist_scope member of DeclarationDescriptor was only used to pass the function
scope for declaration of parameters containing sloppy evals, for example:

  function f(x = eval("var y")) { }

In cases like this, "x" is declared in the function scope but "y" is declared in an inner scope.
Rather than passing the function scope as "hoist_scope", we simply ask for the outer_scope()
of the inner scope as needed in PatternRewriter.

This reduces the cognitive overhead of understanding what a DeclarationDescriptor has; for
example, it removes some dead code from the PreParser which never has to deal
with a situation like the example above.

Review-Url: https://codereview.chromium.org/2662183002
Cr-Commit-Position: refs/heads/master@{#42861}
      59b8496c
  25. 31 Jan, 2017 2 commits
  27. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored 
      They have the same lifetime. It's a match!

Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.

A follow-on CL removes even more parser infrastructure related to this count.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  29. 25 Jan, 2017 1 commit
  31. 23 Jan, 2017 1 commit
  33. 20 Jan, 2017 1 commit
    • marja's avatar
      Parsing: Create the same scopes for non-simple params in PreParser & Parser. · 35340917
      marja authored 
      Rationale:

- To do scope analysis based on PreParser, and use the result again when parsing
  later, PreParser and Parser need to produce the same Scopes and variable
  declarations in them.

- This is not the case for non-simple parameters: Parser creates an additional
  inner Scope where the declarations were, whereas PreParser does
  DeclareVariableName directly in the function Scope.

- So this CL fixes that by moving the Scope creation for non-simple parameters
  into ParserBase.

- As a side product (and a partial proof that this change makes sense),
  PreParser::ParseEagerFunctionBody is now gone.

BUG=v8:5516

Review-Url: https://codereview.chromium.org/2638333002
Cr-Commit-Position: refs/heads/master@{#42537}
      35340917
  35. 19 Jan, 2017 1 commit
  37. 18 Jan, 2017 4 commits
  39. 17 Jan, 2017 2 commits
  41. 16 Jan, 2017 3 commits
  43. 12 Jan, 2017 1 commit
  45. 10 Jan, 2017 1 commit
  47. 09 Jan, 2017 1 commit