Skip to content

V
V8
Switch branch/tag
  1. 05 Jul, 2022 3 commits
  3. 13 May, 2022 1 commit
  5. 03 Mar, 2022 1 commit
  7. 10 Feb, 2022 1 commit
  9. 26 Jan, 2022 1 commit
  11. 24 Jan, 2022 1 commit
    • Joyee Cheung's avatar
      Reland "[class] implement reparsing of class instance member initializers" · 0e07eb53
      Joyee Cheung authored 
      This is a reland of 91f08378

When the class scope does not need a context, the deserialized
outer scope of the initializer scope would not be the class scope,
and we should not and do not need to use it to fix up the allocation
information of the context-allocated variables. The original patch
did not consider this case and resulted in a regression when we
tried to reparse the initializer function to look for destructuring
assignment errors. This fixes the regression by not deserializing
the class scope that's going to be reparsed, and using the positions
of the scopes to tell whether the scope info matches the reparsed
scope and can be used to fix up the allocation info.

Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
>   entire class so that we can rewind the scanner to parse the class
>   body to collect initializers (previously, it starts from the first
>   field initializer and ends at the last initializer). This resulted
>   some expectation changes in the debugger tests, though the
>   initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
>   is reparsed, we use the information from the ScopeInfo to update
>   the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}

Bug: chromium:1278086, chromium:1278085, v8:10704
Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78745}
      0e07eb53
  13. 19 Jan, 2022 1 commit
  15. 09 Dec, 2021 1 commit
    • Joyee Cheung's avatar
      Revert "[class] implement reparsing of class instance member initializers" · f668e9f7
      Joyee Cheung authored 
      This reverts commit 91f08378.

Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.

Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
>   entire class so that we can rewind the scanner to parse the class
>   body to collect initializers (previously, it starts from the first
>   field initializer and ends at the last initializer). This resulted
>   some expectation changes in the debugger tests, though the
>   initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
>   is reparsed, we use the information from the ScopeInfo to update
>   the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}

Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
      f668e9f7
  17. 08 Dec, 2021 1 commit
    • Joyee Cheung's avatar
      [class] implement reparsing of class instance member initializers · 91f08378
      Joyee Cheung authored 
      Previously, since the source code for the synthetic class instance
member initializer function was recorded as the span from the first
initializer to the last initializer, there was no way to reparse the
class and recompile the initializer function. It was working for
most use cases because the code for the initializer function was
generated eagarly and it was usually alive as long as the class was
alive, so the initializer wouldn't normally be lazily parsed. This
didn't work, however, when the class was snapshotted with
v8::SnapshotCreator::FunctionCodeHandling::kClear,
becuase then we needed to recompile the initializer when the class
was instantiated. This patch implements the reparsing so that
these classes can work with FunctionCodeHandling::kClear.

This patch refactors ParserBase::ParseClassLiteral() so that we can
reuse it for both parsing the class body normally and reparsing it
to collect initializers. When reparsing the synthetic initializer
function, we rewind the scanner to the beginning of the class, and
parse the class body to collect the initializers. During the
reparsing, field initializers are parsed with the full parser while
methods of the class are pre-parsed.

A few notable changes:

- Extended the source range of the initializer function to cover the
  entire class so that we can rewind the scanner to parse the class
  body to collect initializers (previously, it starts from the first
  field initializer and ends at the last initializer). This resulted
  some expectation changes in the debugger tests, though the
  initializers remain debuggable.
- A temporary ClassScope is created during reparsing. After the class
  is reparsed, we use the information from the ScopeInfo to update
  the allocated indices of the variables in the ClassScope.

Bug: v8:10704
Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78299}
      91f08378
  19. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored 
      Add suppose for compiling non-eager, non-top-level inner functions in
parallel, using the compiler dispatcher. This behaviour can be enabled
with --parallel-compile-tasks-for-lazy.

There are a couple of consequences:

  * To support this we need support for off-thread ScopeInfo
    deserialization, so this adds that too.
  * The previous --parallel-compile-tasks flag is renamed to the more
    descriptive --parallel-compile-tasks-for-eager-toplevel.
  * Both parallel-compile-tasks flags are moved onto
    UnoptimizedCompileFlags so that they can be enabled/disabled on a
    per-compile basis (e.g. enabled for streaming, disabled for
    re-parsing).
  * asm.js compilations can now happen without an active Context (in
    the compiler dispatcher's idle finalization) so we can't get a
    ContextId for metric reporting; we'd need to somehow fix this if we
    wanted asm.js UKM but for now it's probably fine.
  * Took the opportunity to clean up some of the "can preparse" logic in
    the parser.

Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  21. 16 Nov, 2021 1 commit
  23. 26 Apr, 2021 1 commit
  25. 15 Mar, 2021 1 commit
  27. 29 Jan, 2021 1 commit
  29. 28 Jan, 2021 1 commit
    • Marja Hölttä's avatar
      Revert "Reland [super] Store home object in Context instead of JSFunction" · 12f8ac47
      Marja Hölttä authored 
      This reverts commit f6450b97.

Reason for revert: ClusterFuzz bugs

Original change's description:
> Reland [super] Store home object in Context instead of JSFunction
>
> 1) Computed property keys (esp functions in them) shouldn't be inside
> the object literal scope.
>
> 2) I was using an imprecise "maybe uses super" and storing it to
> preparse data. This won't fly, since it pollutes sister scopes and
> leads to confusion wrt whether an object literal needs a home object
> or not. Made it precise (mostly cancelling changes in the original CL).
>
> 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
> this_function (which made it used) -> inconsistent scopes between
> parsing and preparsing.
>
> 4) MultipleEntryBlockContextScope was messing up the accumulator
>
> Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
> Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72169}

TBR=marja@chromium.org,leszeks@chromium.org

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

Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
      12f8ac47
  31. 19 Jan, 2021 2 commits
  33. 18 Jan, 2021 1 commit
  35. 08 Oct, 2020 1 commit
  37. 19 Aug, 2020 2 commits
  39. 15 Jul, 2020 2 commits
  41. 10 Jul, 2020 1 commit
  43. 08 Jul, 2020 1 commit
  45. 26 May, 2020 1 commit
  47. 11 May, 2020 1 commit
  49. 12 Mar, 2020 1 commit
  51. 02 Mar, 2020 1 commit
  53. 10 Feb, 2020 1 commit
  55. 09 Dec, 2019 2 commits
    • Leszek Swirski's avatar
      [parser] Use non-eval decl scope's parent for caching · fffea681
      Leszek Swirski authored 
      We use the compilation entry point as a caching scope for deserializing
lookups, to avoid redundantly iterating over parent scopes when
accessing the same variable multiple times.

However, this caching scope messes with lookups that are looking for
lexical name conflicts, as opposed to just resolving variables. In
particular, it messes with name conflict lookups and sloppy block
function hoisting checks, when there are other scopes in the way, e.g.

    function f() {
      let x;
      try {
        throw 0;
      }
      catch (x) {
        // This catch is the entry scope

        // Naive use of caches will find the catch-bound x (which is
        // a VAR), and declare 'no conflict'.
        eval("var x;");

        // Naive use of caches will find the catch-bound x (which is
        // a VAR), and determine that this function can be hoisted.
        eval("{ function x() {} }");
      }
    }

Previously, we worked around this by avoiding cache uses for these
lookups, but this had the issue of instead caching the same variable
multiple times, on different scopes. In particular, we saw:

    function f() {
      with ({}) {
        // This with is the entry scope, any other scope would do
        // though.

        // The conflict check on `var f` caches the function name
        // variable on the function scope, the subsequent 'real'
        // lookup of `f` caches the function name variable on the
        // entry i.e. with scope.
        eval("var f; f;");
      }
    }

With this patch, we change the caching behaviour to cache on the first
non-eval declaration scope above the eval -- in the above examples, this
becomes the parent function "f". For compilations with no intermediate
non-decl scopes (no with or catch scopes between the function and eval)
this becomes equivalent to the existing entry-point-based caching.

This means that normal lookups do have to (sometimes) iterate more scopes,
and we do have to be careful when using the cache to not use it for
lookups in these intermediate scopes (a new IsOuterScope DCHECK guards
against this), but we can now safely ignore the cache scope when doing
the name-collision lookups, as they only iterate up to the outer
non-eval declaration scope anyway.

Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65391}
      fffea681
    • Leszek Swirski's avatar
      Revert "[parser] Fix variable caching for conflict lookup" · b8fef1a7
      Leszek Swirski authored 
      This reverts commit 026a0c21.

Reason for revert: Reverting due to https://crbug.com/1029461

Original change's description:
> [parser] Fix variable caching for conflict lookup
> 
> During conflict lookup (for lexical variables and sloppy block function
> hoisting), we cache the looked-up variable on the current scope if the
> lookup goes through a ScopeInfo. However, for variable lookup during
> scope analysis, we use the "entry point" as the cache.
> 
> Since both lookups can create Variables, this can cause us to create
> duplicate variables, e.g. a duplicate function name variable in the
> attached test.
> 
> Instead, for ScopeInfo conflict lookups we can cache the result on the
> function's outer scope, which shoud be equivalent to the entry point.
> 
> As a (necessary) drive-by, we can terminate the lookup early if we find
> a VAR with the same name, as we can safely assume that its existence
> means that it doesn't conflict, which means that our variable can't
> conflict either.
> 
> Bug: chromium:1026603
> Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65138}

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

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

Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: Id7f5dd342e32e1bb57c51b3748feff32ee0ba41d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958014Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65390}
      b8fef1a7
  57. 06 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Implement top-level await for REPL mode" · f96f9312
      Simon Zünd authored 
      This is a reland of 5bddc0e1

The original CL was speculatively reverted as it was suspected to
cause failures on the non-determinism bot. This was ultimately
confirmed to not be the case, so this CL is safe to reland as-is.

Original change's description:
> Implement top-level await for REPL mode
>
> Design doc: bit.ly/v8-repl-mode
>
> This CL allows the usage of 'await' without wrapping code in an async
> function when using REPL mode in global evaluate. REPL mode evaluate
> is changed to *always* return a Promise. The resolve value of the
> promise is the completion value of the REPL script.
>
> The implementation is based on two existing mechanisms:
>   - Similar to async functions, the content of a REPL script is
>     enclosed in a synthetic 'try' block. Any thrown error
>     is used to reject the Promise of the REPL script.
>
>   - The content of the synthetic 'try' block is also re-written the
>     same way a normal script is. This is, artificial assignments to
>     a ".result" variable are inserted to simulate a completion
>     value. The difference for REPL scripts is, that ".result" is
>     used to resolve the Promise of the REPL script.
>
>   - ".result" is not returned directly but wrapped in an object
>     literal: "{ .repl_result: .result}". This is done to prevent
>     resolved promises from being chained and resolved prematurely:
>
>     > Promse.resolve(42);
>
>     should evaluate to a promise, not 42.
>
> Bug: chromium:1021921
> Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65273}

TBR: yangguo@chromium.org,verwaest@chromium.org
Bug: chromium:1021921
Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65360}
      f96f9312
  59. 04 Dec, 2019 1 commit
    • Maya Lekova's avatar
      Revert "Implement top-level await for REPL mode" · 99005f33
      Maya Lekova authored 
      This reverts commit 5bddc0e1.

Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863

Original change's description:
> Implement top-level await for REPL mode
> 
> Design doc: bit.ly/v8-repl-mode
> 
> This CL allows the usage of 'await' without wrapping code in an async
> function when using REPL mode in global evaluate. REPL mode evaluate
> is changed to *always* return a Promise. The resolve value of the
> promise is the completion value of the REPL script.
> 
> The implementation is based on two existing mechanisms:
>   - Similar to async functions, the content of a REPL script is
>     enclosed in a synthetic 'try' block. Any thrown error
>     is used to reject the Promise of the REPL script.
> 
>   - The content of the synthetic 'try' block is also re-written the
>     same way a normal script is. This is, artificial assignments to
>     a ".result" variable are inserted to simulate a completion
>     value. The difference for REPL scripts is, that ".result" is
>     used to resolve the Promise of the REPL script.
> 
>   - ".result" is not returned directly but wrapped in an object
>     literal: "{ .repl_result: .result}". This is done to prevent
>     resolved promises from being chained and resolved prematurely:
> 
>     > Promse.resolve(42);
> 
>     should evaluate to a promise, not 42.
> 
> Bug: chromium:1021921
> Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65273}

TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org

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

Bug: chromium:1021921
Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65333}
      99005f33
  61. 02 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Implement top-level await for REPL mode · 5bddc0e1
      Simon Zünd authored 
      Design doc: bit.ly/v8-repl-mode

This CL allows the usage of 'await' without wrapping code in an async
function when using REPL mode in global evaluate. REPL mode evaluate
is changed to *always* return a Promise. The resolve value of the
promise is the completion value of the REPL script.

The implementation is based on two existing mechanisms:
  - Similar to async functions, the content of a REPL script is
    enclosed in a synthetic 'try' block. Any thrown error
    is used to reject the Promise of the REPL script.

  - The content of the synthetic 'try' block is also re-written the
    same way a normal script is. This is, artificial assignments to
    a ".result" variable are inserted to simulate a completion
    value. The difference for REPL scripts is, that ".result" is
    used to resolve the Promise of the REPL script.

  - ".result" is not returned directly but wrapped in an object
    literal: "{ .repl_result: .result}". This is done to prevent
    resolved promises from being chained and resolved prematurely:

    > Promse.resolve(42);

    should evaluate to a promise, not 42.

Bug: chromium:1021921
Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65273}
      5bddc0e1
  63. 25 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Fix variable caching for conflict lookup · 026a0c21
      Leszek Swirski authored 
      During conflict lookup (for lexical variables and sloppy block function
hoisting), we cache the looked-up variable on the current scope if the
lookup goes through a ScopeInfo. However, for variable lookup during
scope analysis, we use the "entry point" as the cache.

Since both lookups can create Variables, this can cause us to create
duplicate variables, e.g. a duplicate function name variable in the
attached test.

Instead, for ScopeInfo conflict lookups we can cache the result on the
function's outer scope, which shoud be equivalent to the entry point.

As a (necessary) drive-by, we can terminate the lookup early if we find
a VAR with the same name, as we can safely assume that its existence
means that it doesn't conflict, which means that our variable can't
conflict either.

Bug: chromium:1026603
Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65138}
      026a0c21
  65. 06 Nov, 2019 1 commit
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored 
      Design doc: bit.ly/v8-repl-mode

This CL adds a new REPL mode that can be used via
DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
of 'let' bindings at the moment. Example:

REPL Input 1: let x = 21;
REPL Input 2: let x = 42;

This would normally throw a SyntaxError, but works in REPL mode.

The implementation is done by:
  - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
    and script {Scope}.
  - Each global let declaration still gets a slot reserved in the
    respective {ScriptContext}.
  - When a new REPL mode {ScriptContext} is created, name clashes
    for let bindings are not reported as errors.
  - Declarations, loads and stores for global let in REPL mode are
    now "load/store global" instead of accessing their respective
    context slot directly. This causes a lookup in the ScriptContextTable
    where the found slot for each name is guaranteed to be the same
    (the first one).

Bug: chromium:1004193, chromium:1018158
Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  67. 05 Nov, 2019 1 commit