1. 18 Feb, 2021 1 commit
  2. 29 Jan, 2021 1 commit
  3. 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
  4. 26 Jan, 2021 1 commit
  5. 19 Jan, 2021 2 commits
  6. 18 Jan, 2021 1 commit
  7. 07 Jan, 2021 1 commit
  8. 26 Nov, 2020 1 commit
  9. 30 Oct, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Add 'l' flag to force experimental engine · 5720d205
      Martin Bidlingmaier authored
      This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
      that forces execution in linear time.  These regexps are handled by the
      experimental engine.  If the experimental engine cannot handle the
      pattern, an exception is thrown on creation of the regexp.
      
      The commit also adds a new global V8 flag and changes an existing one:
      * --enable-experimental-engine, which turns on recognition of the RegExp
        'l' flag.  Previously this flag also caused all supported regexps to
        be executed by the experimental engine; this is not the case anymore.
      * --default-to-experimental-regexp-engine takes over the previous
        semantics of --enable-experimental-regexp-engine:  We execute all
        supported regexps with the experimental engine.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Cr-Commit-Position: refs/heads/master@{#70892}
      5720d205
  10. 29 Apr, 2020 2 commits
  11. 09 Mar, 2020 1 commit
  12. 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
  13. 20 Feb, 2020 1 commit
  14. 18 Feb, 2020 1 commit
  15. 11 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. 16 Jan, 2020 1 commit
    • 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
  19. 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
  20. 27 Nov, 2019 1 commit
  21. 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
  22. 30 Oct, 2019 1 commit
  23. 10 Oct, 2019 1 commit
    • Joyee Cheung's avatar
      [class] fix undefined private name access in computed property keys · 7fa12e2a
      Joyee Cheung authored
      This patch implements https://github.com/tc39/proposal-class-fields/pull/269
      and makes sure we always throw TypeError when there is invalid private
      name access in computed property keys.
      
      Before this patch, private name variables of private fields and methods
      are initialized together with computed property keys in the order they
      are declared. Accessing undefined private names in the computed property
      keys thus fail silently.
      
      After this patch, we initialize the private name variables of private
      fields before we initialize the computed property keys, so that invalid
      access to private fields in the computed keys can be checked in the IC.
      We now also initialize the brand early, so that invalid access to private
      methods or accessors in the computed keys throw TypeError during brand
      checks - and since these accesses are guarded by brand checks, we can
      create the private methods and accessors after the class is
      defined, and merge the home object setting with the creation
      of the closures.
      
      Bug: v8:8330, v8:9611
      Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64225}
      7fa12e2a
  24. 30 Aug, 2019 1 commit
    • Leszek Swirski's avatar
      Reland "[destructuring] Elide coercible check for simple keys" · ef2df57a
      Leszek Swirski authored
      This is a reland of 1fba0441
      Chromium expectation tests have been disabled, and will be enabled
      
      Original change's description:
      > [destructuring] Elide coercible check for simple keys
      >
      > Simple object destructuring, such as `let {a,b} = o`, is less efficient
      > than the equivalent assignments `let a = o.a; let b = o.b`. This is
      > because it does a nil check of `o` before the assignments. However, this
      > nil check is not strictly necessary for simple (i.e. non-computed) names,
      > as there will be an equivalent nil check on the first access to o in
      > `o.a`. For computed names the computation is unfortunately obervable.
      >
      > So, we can elide the nil check when the first property (if any) of the
      > destructuring target is a non-computed name. This messes a bit with our
      > error messages, so we re-use the CallPrinter to also find destructuring
      > assignment based errors, and fiddle with the error message there. As
      > a side-effect, we also get out the object name in the AST, so we can
      > output a slightly nicer error message.
      >
      > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63453}
      
      TBR=verwaest@chromium.org
      
      Bug: chromium:999473
      Change-Id: Ib0b2e4be433c50521ba1722e1c06b672bfefa405
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777702Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63477}
      ef2df57a
  25. 29 Aug, 2019 2 commits
    • Adam Klein's avatar
      Revert "[destructuring] Elide coercible check for simple keys" · 28fa4cb4
      Adam Klein authored
      This reverts commit 1fba0441.
      
      Reason for revert: blocks V8 roll due to layout test failures caused by error message changes:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347
      
      Original change's description:
      > [destructuring] Elide coercible check for simple keys
      > 
      > Simple object destructuring, such as `let {a,b} = o`, is less efficient
      > than the equivalent assignments `let a = o.a; let b = o.b`. This is
      > because it does a nil check of `o` before the assignments. However, this
      > nil check is not strictly necessary for simple (i.e. non-computed) names,
      > as there will be an equivalent nil check on the first access to o in
      > `o.a`. For computed names the computation is unfortunately obervable.
      > 
      > So, we can elide the nil check when the first property (if any) of the
      > destructuring target is a non-computed name. This messes a bit with our
      > error messages, so we re-use the CallPrinter to also find destructuring
      > assignment based errors, and fiddle with the error message there. As
      > a side-effect, we also get out the object name in the AST, so we can
      > output a slightly nicer error message.
      > 
      > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63453}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63465}
      28fa4cb4
    • Leszek Swirski's avatar
      [destructuring] Elide coercible check for simple keys · 1fba0441
      Leszek Swirski authored
      Simple object destructuring, such as `let {a,b} = o`, is less efficient
      than the equivalent assignments `let a = o.a; let b = o.b`. This is
      because it does a nil check of `o` before the assignments. However, this
      nil check is not strictly necessary for simple (i.e. non-computed) names,
      as there will be an equivalent nil check on the first access to o in
      `o.a`. For computed names the computation is unfortunately obervable.
      
      So, we can elide the nil check when the first property (if any) of the
      destructuring target is a non-computed name. This messes a bit with our
      error messages, so we re-use the CallPrinter to also find destructuring
      assignment based errors, and fiddle with the error message there. As
      a side-effect, we also get out the object name in the AST, so we can
      output a slightly nicer error message.
      
      Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254Reviewed-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@{#63453}
      1fba0441
  26. 07 Aug, 2019 1 commit
  27. 30 Jul, 2019 1 commit
    • Joyee Cheung's avatar
      [class] parse private accessors · a6dd7f1c
      Joyee Cheung authored
      This patch adds:
      
      - VariableMode::kPrivateMethod
      - VariableMode::kPrivateSetterOnly
      - VariableMode::kPrivateGetterOnly
      - VariableMode::kPrivateGetterAndSetter
      
      And replace the previous RequiresBrandCheckFlag by inferring
      whether the brand check is required from these VariableModes.
      It is then possible to check duplicate non-complementary
      accessors in the parsers and throw early errors, and allow
      complementary accessors to be associated with the same
      private name variable.
      
      This patch also adds the following AssignType:
      
      - PRIVATE_METHOD
      - PRIVATE_GETTER_ONLY
      - PRIVATE_SETTER_ONLY
      - PRIVATE_GETTER_AND_SETTER
      
      corresponding to the new VariableModes so that it's possible
      to generate specialized code for different type of
      private accessor declarations.
      
      Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
      
      Bug: v8:8330
      Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62988}
      a6dd7f1c
  28. 18 Jun, 2019 1 commit
  29. 24 May, 2019 1 commit
  30. 23 May, 2019 2 commits
  31. 21 May, 2019 1 commit
  32. 13 May, 2019 1 commit
  33. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored
      This reverts commit b9191bd3.
      
      Reason for revert: Clusterfuzz bugs
      BUG=chromium:961507,chromium:961508
      
      Original change's description:
      > [class] implement private method declarations
      >
      > This patch implements the declarations of private methods, the access
      > of private methods would be left to a future patch.
      > When a private methods declaration is encountered, we now:
      >
      > - Create a brand symbol during class evaluation and store it in the
      >   context.
      > - Create the closures for the private methods
      > - Load the brand from the context and store it in the instance in the
      >   constructor.
      >
      > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
      >
      > Bug: v8:8330
      > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61387}
      
      TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
      
      Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  34. 09 May, 2019 1 commit
  35. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  36. 26 Feb, 2019 1 commit