Skip to content

V
V8
Switch branch/tag
  1. 11 Jul, 2019 2 commits
    • Michael Starzinger's avatar
      [wasm] Fix importing of re-exported JavaScript callable. · f71ccd7a
      Michael Starzinger authored 
      This fixes a corner-case where a {WasmExportedFunction} that represents
a re-export of a JavaScript callable from another module was identified
correctly, but not all corner-cases were correctly covered. Concretely
we failed to check for function signatures incompatible with JavaScript.

R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-9447
BUG=v8:9447

Change-Id: Ia6c73c82f4c1b9c357c08cde039be6af100727d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690941
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62632}
      f71ccd7a
    • Dan Elphick's avatar
      Revert "[parsing] Improve elision of hole checks for default parameters" · a61ce8a0
      Dan Elphick authored 
      This reverts commit e8d86597.

Reason for revert: crbug.com/981701

Original change's description:
> [parsing] Improve elision of hole checks for default parameters
> 
> Use the position of the next parameter to be declared as the end of the
> initializer for default parameters, so that hole checks can be elided
> for initializers using previous parameters in arrow functions.
> 
> This fixes a source of bytecode mismatches when collecting source
> positions lazily.
> 
> Bug: chromium:980422, v8:8510
> Change-Id: I5ab074231248b661156e7d8e47c01685448b56d5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683267
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62525}

TBR=verwaest@chromium.org,delphick@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:980422, v8:8510
Change-Id: I3abd70a1fb00967e58b46177655a0078e24db720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697242Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62630}
      a61ce8a0
  3. 09 Jul, 2019 3 commits
  5. 08 Jul, 2019 2 commits
  7. 04 Jul, 2019 1 commit
  9. 03 Jul, 2019 3 commits
  11. 01 Jul, 2019 5 commits
    • Clemens Hammacher's avatar
      [ubsan] Fix integer overflow in compiler · a420d20c
      Clemens Hammacher authored 
      Negating the maximum int32 failed in ubsan. Use
{base::NegateWithWraparound} to avoid UB.

R=jkummerow@chromium.org

Bug: chromium:980007
Change-Id: If52a3bb3158eb5b465e7bd29deaffc0b18660360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683993Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62470}
      a420d20c
    • Michael Starzinger's avatar
      [asm.js] Fix undefined cast from double to float. · f03430fe
      Michael Starzinger authored 
      This fixes undefined behavior in the implicit cast from double to float
when a double literal is passed through {fround} while declaring a local
variable.

R=jkummerow@chromium.org
TEST=mjsunit/regress/regress-crbug-976934
BUG=chromium:976934

Change-Id: I0efa2bf3f89d32c445f0b9bf719880d17fe9743c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683999Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62469}
      f03430fe
    • Jakob Kummerow's avatar
      [test] Speed up regress-crbug-319860.js · afdda800
      Jakob Kummerow authored 
      This reduces the time it takes to run this test in --jitless mode
from 32s to 0.7s.

Bug: v8:9416
Change-Id: Ie9a7465b604b28ff8ccaa50f0918c62e3128ac08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682575
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62464}
      afdda800
    • Jakob Gruber's avatar
      [regexp] Fix BoyerMooreLookahead behavior at submatches · bc4cbe92
      Jakob Gruber authored 
      Since https://codereview.chromium.org/2777583003, the Boyer-Moore
lookahead (used by the irregexp engine) also looks inside submatches
to narrow down its range of accepted characters at specific offsets.

But the end of a submatch, designated by a PositiveSubmatchSuccess
action node, was not handled correctly. When a submatch terminates,
we have no knowledge of what may follow, and thus must accept any
character at following positions. This is done by the SetRest call
added in this CL.

An example, since this is fairly obscure:

/^.*?Y(((?=B?).)*)Y$/s

The initial non-greedy loop, together with the s flag,
will trigger an attempted Boyer-Moore lookahead. After this follows
an unconditional Y, a *-quantified loop matching any char and
containing a lookahead that matches either 1 B or 0 B's, and an
unconditional trailing Y.

When the BM lookahead scans the subject string for the beginning of
this pattern after the non-greedy loop, it should look for: a Y at
offset 0, and either a B, a Y, or '.' (-> any character) at offset 1.

Prior to this CL this was not the case:

- The lookaround is internally generated as a submatch.
- The optional 'B?' is unrolled into 'either B followed by submatch
  end' or 'submatch end'.
- Filling in BM infos terminates when encountering a submatch end.
  Thus in the former case we added B to the set of accepted characters
  and terminated, while in the latter case we simply terminated.o

This CL ensures that BM will accept any character at any offset at or
exceeding the first encountered submatch end.

Bug: v8:8770
Change-Id: Iff998ba307cd9669203846a9182798b8cf6a85dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679506
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarErik Corry <erikcorry@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62460}
      bc4cbe92
    • Leszek Swirski's avatar
      [parser] Mark maybe_assigned recursively for shadowing vars · fc4bcce1
      Leszek Swirski authored 
      The previous fix for this bug (crrev.com/c/1678365) pessimistically
would mark all shadowed variables as maybe_assigned. Unfortunately,
this doesn't work across a parse/preparse boundary, where the shadowing
variable is found via Scope::AnalyzePartially while the shadowed
variable is outside of the preparser entry point. In those cases, the
referencing proxy is copied to the outer scope, in which case the
dynamicness of the original lookup is lost and the maybe_assigned
pessimisation no longer applies.

This means that maybe_assigned status of a variable is dependent on
which function is being parsed. In particular, it can cause bytecode
to change on recompilation, causing issues for lazy source positions.

This patch allows SetMaybeAssigned to walk its shadowed variables,
and recursively set them to maybe_assigned too. Checking for
maybe_assigned changing prevents this recursion from having a
quadratic performance failure mode.

Bug: v8:8510
Bug: v8:9394
Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62458}
      fc4bcce1
  13. 28 Jun, 2019 2 commits
  15. 27 Jun, 2019 3 commits
    • Z Nguyen-Huu's avatar
      Add GetPropertyWithReceiver stub for proxy get trap · a7732341
      Z Nguyen-Huu authored 
      GetPropertyWithReceiver is similar to GetProperty, except that additional receiver parameter is used in TryPrototypeChainLookup to support GetPropertyWithReceiver stub.
We only use this stub in ProxyGetProperty builtin for now.

Bug: v8:8958
Change-Id: Ied60e4f6ee6e09bca2f161048b481a0bf37a78a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676879
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62431}
      a7732341
    • Mathias Bynens's avatar
      [test] Remove module pragma in favor of .mjs · 5c2c5ce1
      Mathias Bynens authored 
      d8 treats files with the .mjs extension as modules instead of
classic scripts. Thus, the `// MODULE` pragma and its corresponding
logic in test runners can be removed in favor of explicitly adding
the extension.

Bug: v8:7950, v8:9395, v8:9406
Also-By: tmrts@chromium.org
Change-Id: Ic74328dc5c5f176bb4bdf6d74bdd4d3966279ba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675958
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62421}
      5c2c5ce1
    • Leszek Swirski's avatar
      [parser] Always mark shadowed vars maybe_assigned · e79751b3
      Leszek Swirski authored 
      If there was an assignment to a maybe-shadowing dynamic variable,
then the shadowing variable would be marked maybe_assigned, but the
maybe-shadowed variable would stay unchanged. This meant that in
non-shadowing cases, the not-actually-shadowed variable would have
the wrong maybe_assigned state, and e.g. would break context
specialization.

This patch pessimistically unconditionally sets maybe_assigned on
variables shadowed by a dynamic variable in a `with` scope. This
marking can cause false positives and sub-optimal optimization for
some functions with 'with' blocks, but it's also the simplest fix
for this issue which doesn't affect performance in the common case
of no 'with' blocks.

Bug: v8:9394
Change-Id: I6924bd7d48dda61232aa9d72c39df1c76c665c67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678365
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62407}
      e79751b3
  17. 26 Jun, 2019 3 commits
  19. 24 Jun, 2019 1 commit
  21. 20 Jun, 2019 1 commit
  23. 19 Jun, 2019 2 commits
  25. 18 Jun, 2019 5 commits
  27. 17 Jun, 2019 6 commits
  29. 14 Jun, 2019 1 commit