1. 19 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      Revert "[parser] Introduce UnoptimizedCompileFlags" · fabea6af
      Leszek Swirski authored
      This reverts commit d91679bf.
      
      Reason for revert: Seems to cause UBSan errors
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      > 
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      > 
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      > 
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66783}
      fabea6af
    • Leszek Swirski's avatar
      [parser] Introduce UnoptimizedCompileFlags · d91679bf
      Leszek Swirski authored
      UnoptimizedCompileFlags defines the input flags shared between parse and
      compile (currently parse-only). It is set initially with some values, and
      is immutable after being passed to ParseInfo (ParseInfo still has getters
      for the fields, but no setters).
      
      Since a few of the existing flags were output flags, ParseInfo now has a
      new output_flags field, which will eventually migrate to a ParseOutputs
      structure.
      
      Bug: v8:10314
      Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66782}
      d91679bf
  2. 18 Mar, 2020 1 commit
  3. 12 Mar, 2020 1 commit
  4. 09 Mar, 2020 1 commit
  5. 03 Mar, 2020 1 commit
    • Joyee Cheung's avatar
      [class] maintain private brand information on SFI · 0753cbea
      Joyee Cheung authored
      When an empty class is nested inside a class with private instance
      methods, like this:
      
        class Outer {
          constructor() {}
          #method() {}
          factory() {
            class Inner {
              constructor() {  }
            }
            return Inner;
          }
          run(obj) {
            obj.#method();
          }
        }
      
      The bytecode generator previously generate private brand
      initialization for the constructor of Inner by mistake,
      because during scope chain serialization/deserialization,
      the outer scopes of Inner and factory() are not allocated
      or serialized (as they are empty). In the eyes of the bytecode
      generator, it then appeared as if Outer is the direct outer
      scope of Inner's constructor.
      
      In order to work around this information loss, in this patch
      we rely on SharedFunctionInfo instead of the Context/ScopeInfo
      chain to maintain the information about private brand initialization.
      This is done by shrinking expected_nof_properties to 8 bits and
      freeing 8 bits for a second bitfield on the SFI.
      
      Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
      Bug: v8:9839, v8:8330, v8:10098
      
      Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66575}
      0753cbea
  6. 02 Mar, 2020 1 commit
  7. 20 Feb, 2020 1 commit
  8. 18 Feb, 2020 1 commit
  9. 17 Feb, 2020 1 commit
  10. 13 Feb, 2020 1 commit
  11. 12 Feb, 2020 2 commits
  12. 11 Feb, 2020 1 commit
  13. 10 Feb, 2020 2 commits
  14. 07 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Cache allocated AstConsString · 7fa19160
      Leszek Swirski authored
      Allow caching the result of allocating AstConsStrings, to allow
      sharing of inferred names between functions.
      
      This is a partial revert of https://crrev.com/c/2020953, with
      the observation that *some* AstConsStrings are always flattened,
      while others are only ever used as ConsStrings, so we want to
      allow the allocation to be lazy while still caching the result.
      
      As a drive-by, cleanup the old AstConsString linked list fields.
      
      Bug: chromium:1011762
      Bug: chromium:1048082
      Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66168}
      7fa19160
  15. 06 Feb, 2020 1 commit
  16. 05 Feb, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [callprinter] Correctly point to the incorrect spread arg · 1d0693e2
      Sathya Gunasekaran authored
      The source position is set to the function call (console.log) not the
      spread (..x), in the bytecode generator, as the spread operation is
      done as part of the CallWithSpread bytecode.
      
      The CallPrinter stops at the function call and doesn't look at the
      arguments as well (in CallPrinter::VisitCall) to see if the error is
      from an incorrect spread operation.
      
      
      With this patch, we pass some state to the CallPrinter in the
      CallWithSpread error case and check that in CallPrinter::VisitCall
      before returning.
      
      For the given source string:
      ```
      x = undefined;
      console.log(1, ...x);
      ```
      
      Previously, the error was -
      
      ```
      test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
      console.log(1, ...x);
              ^
      TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
          at test.js:2:9
      ```
      
      
      Now, the error is -
      
      ```
      _test.js:2: TypeError: x is not iterable (cannot read property undefined)
      console.log(1, ...x);
                        ^
      TypeError: x is not iterable (cannot read property undefined)
          at _test.js:2:9
      ```
      
      Bug: v8:10038
      Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66131}
      1d0693e2
  17. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  18. 30 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Allocate cons strings on-demand · ddca3606
      Leszek Swirski authored
      Remove AstConsString "internalization", and instead make the conversion
      to heap String be on-demand with an Allocate method. We never actually
      need the heapified cons string more than once, so there's no need to do
      the internalization walk or do the next/string union dance in the
      AstConsString class.
      
      This also allows us to specify how we want to allocate the String at the
      call site. In particular, it allows us to allocate a flat SeqString rather
      rather than a ConsString. This allows us to avoid allocating ConsStrings
      which will just be passed to a flatten call, and especially avoid
      allocating dead ConsStrings in the off-thread old space.
      
      Bug: chromium:1011762
      Bug: chromium:1043168
      Change-Id: Id851f2f7529d92ad7e5388eb22823fd6d1959cd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020953Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66042}
      ddca3606
  19. 29 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Allocate cons strings in young space on main thread · 60f108f9
      Leszek Swirski authored
      In the case of function names, we allocate ConsStrings only to flatten
      them during finalization. Allocating these ConsStrings in old space
      appears to have regressed some benchmarks (especially memory benchmarks),
      but is necessary for off-thread allocation which doesn't have a young
      space.
      
      Ideally, we would avoid allocating these ConsStrings in the first place,
      and would flatten the data directly from the AstConsString. For now, we
      make them allocate in old space for off-thread allocation only, to
      revert the regressions. In the future we can investigate smarter
      flattening.
      
      Bug: chromium:1011762
      Bug: chromium:1044477, chromium:1044147, chromium:1043573, chromium:1043168
      Change-Id: If24b738d6f2eeb8c0fea042a711deb2a19015fbd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020948
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66025}
      60f108f9
  20. 27 Jan, 2020 1 commit
  21. 17 Jan, 2020 1 commit
  22. 16 Jan, 2020 2 commits
    • Leszek Swirski's avatar
      [ast] Pre-walk array literals to detect all-doubles · dabc6eb5
      Leszek Swirski authored
      When buildin an array boilerplate description, we currently walk the
      array literal as if it had tagged pointers, and post-hoc copy it to
      a FixedDoubleArray if it had double elements kind.
      
      Now, we calculate the elements kind during the InitDepthAndFlags walk,
      and if the elements kind is Double, we allocate a FixedDoubleArray to
      start with, and convert the elements of the array literal directly to
      unboxed doubles in the array.
      
      Change-Id: I56561e0af2236e785498eb70cb37eddcb09a56ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002529
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65817}
      dabc6eb5
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  23. 14 Jan, 2020 2 commits
    • Leszek Swirski's avatar
      [parser] Fix cache scope recursion for `with` · a85d74a3
      Leszek Swirski authored
      The fix in https://crrev.com/c/1997135 didn't properly recurse the cache
      scope after a with scope, passing the current scope rather than the
      original cache scope up the recursion. Now the "use external cache" check
      is done in LookupWith (and, analogously, LookupSloppyEval) while passing
      the given cache scope through the Lookup recursion.
      
      Fixed: chromium:1041210
      Fixed: chromium:1041616
      Change-Id: I5ac9ddc6c16d63b59aa034721fccec2f7781c4f8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000133
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65754}
      a85d74a3
    • Maya Lekova's avatar
      Revert "[parser] Fix caching dynamic vars on wrong scope" · 2f820780
      Maya Lekova authored
      This reverts commit 304e97d3.
      
      Reason for revert: Last roll is failing - https://ci.chromium.org/p/chromium/builders/try/linux-rel/282356
      
      Original change's description:
      > [parser] Fix caching dynamic vars on wrong scope
      > 
      > When looking up a variable in a deserialized WITH scope, we were
      > unconditionally passing in the cache scope to the lookup, even if the
      > with was inside the cache scope. This would lead to and outer scope of
      > the with holding the generated dynamic variable. If the cache scope was
      > the SCRIPT scope, the dynamic variable would be interpreted as a global
      > object property.
      > 
      > Now, we only store the WITH scope dynamic variables in the cache scope
      > if it is an inner scope of the WITH scope, same as we do for 'normal'
      > scope lookups.
      > 
      > Fixed: chromium:1041210
      > Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65732}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I7b6d77d03b603152a9a47541db466934f46b1176
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000140Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65747}
      2f820780
  24. 13 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [parser] Fix caching dynamic vars on wrong scope · 304e97d3
      Leszek Swirski authored
      When looking up a variable in a deserialized WITH scope, we were
      unconditionally passing in the cache scope to the lookup, even if the
      with was inside the cache scope. This would lead to and outer scope of
      the with holding the generated dynamic variable. If the cache scope was
      the SCRIPT scope, the dynamic variable would be interpreted as a global
      object property.
      
      Now, we only store the WITH scope dynamic variables in the cache scope
      if it is an inner scope of the WITH scope, same as we do for 'normal'
      scope lookups.
      
      Fixed: chromium:1041210
      Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65732}
      304e97d3
  25. 09 Jan, 2020 1 commit
    • Dan Elphick's avatar
      [parser] Force stable order for variables · c8ab41eb
      Dan Elphick authored
      When parsing an arrowhead, it's possible for temporary variables to be
      created with a different index depending on whether the parsing is lazy
      or eager. This then results in bytecode mismatches as the index is used
      to determine which register to use.
      
      To make the ordering stable, this changes variable allocation in arrow
      functions to always allocate the non-temporaries first and then the
      temporaries.
      
      Bug: chromium:1020162
      Change-Id: Ia47c4c2916d63f12d20d663e4e3842bfd68f6d8e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977865
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65657}
      c8ab41eb
  26. 08 Jan, 2020 2 commits
  27. 07 Jan, 2020 2 commits
  28. 02 Jan, 2020 1 commit
  29. 27 Dec, 2019 1 commit
    • Daniel Clifford's avatar
      Port bitfield ScopeFlags to Torque · 7e8a197c
      Daniel Clifford authored
      In the process:
      
      * Rework the Torque definition of ScopeInfo to enable direct
        field-style access of ScopeFlags, removing some dead code in
        the process.
      * Allow implicit FromConstexpr conversion from subtypes of
        'constexpr A' to other types. This makes it possible/easy to
        convert constexpr versions of enums to other types, since the
        constexpr version of the enum isn't addressable. It's namespace
        isn't a valid namespace and is an implementation detail anyway.
      * Cleanup LanguageMode: Language mode is now an enum and directly
        mirrors the C++-side definition rather than being a Smi. With
        the changes above, a new type LanguageModeSmi is introduced
        that is the Smi representation of LanguageMode that can be
        implicitly casted from constexpr LanguageMode values.
      
      Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65561}
      7e8a197c
  30. 18 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Store JSMessageObject on rejected promises · b15c02d0
      Simon Zünd authored
      When V8 throws an uncaught exception, we store a JSMessageObject
      with a stack trace and source positions on the isolate itself.
      The JSMessageObject can be retrieved by a TryCatch scope
      and is used by the inspector to provide additional information to the DevTools
      frontend (besides the exception).
      
      Introducing top-level await for REPL mode causes all thrown exceptions
      to be turned into a rejected promise. The implicit catch block that does this
      conversion clears the JSMessageObject from the isolate as to not leak memory.
      
      This CL preserves the JSMessageObject when the debugger is active and stores
      the JSMessageObject on the rejected promise itself. The inspector is changed
      to retrieve the JSMessageObject in the existing catch handler and pass the
      information along to the frontend.
      
      Drive-by: This CL removes a inspector test that made assumptions when a promise
      is cleaned up by the GC. These assumptions no longer hold since we hold on to
      the promise longer.
      
      Bug: chromium:1021921
      Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65497}
      b15c02d0
  31. 13 Dec, 2019 1 commit
  32. 10 Dec, 2019 1 commit
  33. 09 Dec, 2019 1 commit
    • 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