Skip to content

V
V8
Switch branch/tag
  1. 21 Jul, 2017 1 commit
  3. 19 Jul, 2017 1 commit
    • Daniel Ehrenberg's avatar
      [parser] Prohibit async functions and generators in invalid contexts · ee15703e
      Daniel Ehrenberg authored 
      Async functions and generator declarations are only permitted as
StatementListItems, not as ExpressionStatements, and therefore not
as the entire body of an if statement, etc. Previously, they were
incorrectly permitted. However, ChakraCore and SpiderMonkey seem
to ban them in this context, and the feature was introduced relatively
recently, so it is likely to be web-compatible to ship the prohibition.

This patch also unifies the error message wording of async functions
and generators to ordinary functions, explaining more clearly what
the issue is.

Bug: v8:4483
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I31ed7818d6ab3e7e325031bfabb933dbf4512143
Reviewed-on: https://chromium-review.googlesource.com/568979
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46770}
      ee15703e
  5. 14 Jul, 2017 6 commits
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored 
      Goal of this CL: explicit return from non-async function has position after
return expression as return position (will unblock [1]).

BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
If one of these methods is called then next generated bytecode will get passed
position. It's general treatment for most cases.
Unfortunately it doesn't work for Returns:
- debugger requires source positions exactly on kReturn bytecode in stepping
  implementation,
- BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
  generates more then one bytecode and general solution will put return position
  on first generated bytecode,
- it's not easy to split BuildReturn function into two parts to allow something
  like following in BytecodeGenerator::VisitReturnStatement since generated
  bytecodes are actually controlled by execution_control().
..->BuildReturnPrologue();
..->SetReturnPosition(stmt);
..->Return();

In this CL we pass ReturnStatement through ExecutionControl and use it for
position when we emit return bytecode right here.

So this CL only will improve return position for returns inside of non-async
functions, I'll address async functions later.

[1] https://chromium-review.googlesource.com/c/543161/

Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
Reviewed-on: https://chromium-review.googlesource.com/560738
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored 
      SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.

As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:

- Modification of MacroAssembler AssertGeneratorObject. No longer
  accepts a SuspendFlags parameter to determine which type of check to
  perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
  GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
  AccessBuilders associated with the [[await_input_or_debug_pos]] field
  in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
  prevent the need for the other SuspendFlag values.

BUG=v8:5855
TBR=bmeurer@chromium.org

Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
    • jgruber's avatar
      [coverage] Support conditional expressions · 8f6303fb
      jgruber authored 
      Bug: v8:6000
Change-Id: I8c068383300ba869a87f836504c84ea08fcff87e
Reviewed-on: https://chromium-review.googlesource.com/568307Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46675}
      8f6303fb
    • Caitlin Potter's avatar
      [async-await] desugar Await in BytecodeGenerator · 8b5b444a
      Caitlin Potter authored 
      This includes several changes. From most to least interesting:

- No longer implement AwaitExpressions using a do-expression.
- Reduces frame-size of async generators by not allocating temporary
  variables to hold results of Await epxressions.
- Streamline and reduce generated bytecodes for Await.
- Debugger no longer emits a debug::kCallBreakLocation breakpoint for
the JS-builtin call performed for Await, and instead only emits such
a breakpoint if the operand of Await is actually a call.
- Push fewer parameters to Await* builtins, using the receiver for the
  first parameter (possible now that the CallRuntime invocation not
  part of the AST).
- Adds a new Await AST node. No new members or anything, but it seemed
  palatable to avoid having `if (is_await())` in a number of
  VisitSuspend functions.

BUG=v8:5855, v8:5099, v8:4483
R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org
TBR=bmeurer@chromium.org

Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
Reviewed-on: https://chromium-review.googlesource.com/558806
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46666}
      8b5b444a
    • jgruber's avatar
      [coverage] Support for-of and for-in loops · 5162488a
      jgruber authored 
      Bug: v8:6000
Change-Id: Ia50108ebbf838e210d95cb268858394e6a66c88d
Reviewed-on: https://chromium-review.googlesource.com/567990
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46658}
      5162488a
    • Sathya Gunasekaran's avatar
      [parser] Update {Binding,Assignment}RestPattern · 755d09e6
      Sathya Gunasekaran authored 
      Only allow BindingIdentifier in BindingRestPattern and 
ValidReferenceExpression in AssignmentRestPattern.

Also updated to a better, actionable error message.

Bug: v8:6500, v8:6513
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ifaba2f85c20bc20e263267e8c76d50a27075b87d
Reviewed-on: https://chromium-review.googlesource.com/550559
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46653}
      755d09e6
  7. 13 Jul, 2017 4 commits
  9. 12 Jul, 2017 2 commits
  11. 11 Jul, 2017 2 commits
  13. 10 Jul, 2017 2 commits
    • Alexey Kozyatinskiy's avatar
      Reland "[parser] moved load property position after dot" · 61ea3243
      Alexey Kozyatinskiy authored 
      This is a reland of 5b44ba0e
Original change's description:
> (Reland) [parser] moved load property position after dot
> 
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
> 
> R=jgruber@chromium.org
> TBR=marja@chromium.org
> 
> Bug: v8:6425
> Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
> Reviewed-on: https://chromium-review.googlesource.com/562879
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46484}

TBR=marja@chromium.org,jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng

Bug: v8:6425
Change-Id: I5eba5fe43ad31c5c781ffcc8c604cd9c98baa57e
Reviewed-on: https://chromium-review.googlesource.com/565907Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46542}
      61ea3243
    • Caitlin Potter's avatar
      [parser] avoid for-loop desugaring unless loop var may be captured · 10b9c019
      Caitlin Potter authored 
      In https://chromium-review.googlesource.com/c/472247/, I avoided
running DesugarLexicalBindingsInForStatement() if there were no lexical
loop variables, the function was not resumable, and the variables are
not captured by eval or a function declaration.

I think it's now possible to limit this further, and only do the more
extensive desugaring if there's a function declaration / eval() call
in the loop body. `yield` and `await` are not an issue as those loop
variables are written to the register file and not lost.

This change just removes the `is_resumable()` condition. If it passes
tests, I think it's safe.

BUG=v8:4762, v8:5460, v8:6579

Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a
Reviewed-on: https://chromium-review.googlesource.com/563587
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46536}
      10b9c019
  15. 08 Jul, 2017 1 commit
  17. 07 Jul, 2017 2 commits
  19. 06 Jul, 2017 1 commit
  21. 03 Jul, 2017 1 commit
  23. 30 Jun, 2017 2 commits
  25. 29 Jun, 2017 1 commit
  27. 28 Jun, 2017 1 commit
  29. 26 Jun, 2017 2 commits
  31. 25 Jun, 2017 1 commit
  33. 23 Jun, 2017 6 commits
  35. 22 Jun, 2017 3 commits
  37. 21 Jun, 2017 1 commit
    • bakkot's avatar
      Reland "[parser] Forbid \08 in strict strings" · 76078e14
      bakkot authored 
      (Reland: NeedsManualRebaseline'd newly-fixed layout test in Chromium.)

This was never legal; the spec only allows '\0' in strict-mode strings
or templates when not followed by a decimal digit. Previously we were
only enforcing that it not be followed by an _octal_ digit.

This was already fixed for numeric literals, but not for escape
sequences in strings.

BUG=v8:6504

Review-Url: https://codereview.chromium.org/2948903002
Cr-Commit-Position: refs/heads/master@{#46106}
      76078e14