1. 16 Aug, 2022 1 commit
    • Simon Zünd's avatar
      [debug] Fix source position around class literals · 6a8b90c3
      Simon Zünd authored
      This CL builds upon https://crrev.com/c/3284887 (and partly reverts it).
      
      Class literals are a bit iffy when it comes to source position and
      debugging. Mainly the debugger assumes the following invariant:
      When we are paused inside a class scope, then we expect the class's
      BlockContext to be pushed already. On the other hand, when we are
      paused outside a class scope in a function, we don't expect to find
      the class's BlockContext.
      
      The problem is that there are cases where we can either pause
      "inside" or "outside" the class scope. E.g.:
      
        * `var x = class {};` will break on `class` which is inside
          the class scope, so we expect the BlockContext to be pushed
      
        * `new class x {};` will break on `new` which is outside the
          class scope, so we expect the BlockContext to not be pushed
          yet.
      
      The issue with the fix in https://crrev.com/c/3284887 is that it
      adjusted the break position for the bytecode of class literals to
      ALWAYS be after the BlockContext is pushed. This breaks the
      second example above. We need to tighten the fix a bit and only
      defer the break position if the "current source position" is
      inside the class's scope. This way we always guarantee that the
      BlockContext is pushed or not, depending if the source position
      that corresponds to the break position is inside or outside the
      class's scope.
      
      Note 1: The CL updates a lot of the bytecode expectations. This
      is because the class literals are often the first statement in
      the snippet so we don't need to defer the break position.
      
      Note 2: We add a mirrored debugger test to the inspector test so
      the fuzzer can have some more fun.
      
      Fixed: chromim:1350842
      Change-Id: I9b5a409f77be80db674217a685a3fc9f8a0a71cf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827871Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82473}
      6a8b90c3
  2. 18 Jul, 2022 1 commit
    • Liviu Rau's avatar
      [test] Refactor testrunner (4) · b3477fdd
      Liviu Rau authored
       - Removed duplication and unnecessary indirection from all suites testcfgs.
       - Introduced a more comprehensive context to cover both command context and other platform specific concerns.
       - Propagated above context to TestLoader to allow for test counting command execution on all platforms.
       - Wrapped original pool with another class to give it a new interface and allow injecting different implementations in the future.
       - Consolidated progress indicators under a single processor in the pipeline.
       - Consolidated result retention requirements calculation outside of pipeline chain.
       - Refactored LoaderProc and got it under tests.
       - Added some more tests for the standard runner.
       - Extracted BuildConfig class.
      
      
      Bug: v8:12785
      Change-Id: I87be040e91f792a983662bb5a10d55b36a14ea7f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701595Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Liviu Rau <liviurau@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81770}
      b3477fdd
  3. 03 May, 2022 1 commit
  4. 08 Mar, 2022 1 commit
    • Joyee Cheung's avatar
      [ic] name Set/Define/Store property operations more consistently · 0d1ffe30
      Joyee Cheung authored
      For background and reasoning, see
      https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
      This is the first step towards pulling the DefineNamedOwn operation out
      of StoreIC.
      
      Summary of the renamed identifiers:
      
      Bytecodes:
      
      - StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
        normal named property sets like obj.x = 1.
      - StaNamedOwnProperty -> DefineNamedOwnProperty: calls
        DefineNamedOwnIC (previously StoreOwnIC), and emitted for
        initialization of named properties in object literals and named
        public class fields.
      - StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
        for keyed property sets like obj[x] = 1.
      - StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
        DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
        initialization of private class fields and computed public class
        fields.
      - StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
        DefineKeyedOwnPropertyInLiteral runtime function (previously
        DefineDataPropertyInLiteral) and emitted for initialization of keyed
        properties in object literals and static class initializers. (note
        that previously the StoreDataPropertyInLiteral runtime function name
        was taken by object spreads and array literal creation instead)
      - LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
        GetNamedProperty, LdaNamedPropertyFromSuper ->
        GetNamedPropertyFromSuper: we drop the Sta prefix for the property
        store operations since the accumulator use is implicit and to make
        the wording more natural, for symmetry the Lda prefix for the
        property load operations is also dropped.
      
      opcodes:
      
      - (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
        named properties, compiled from SetNamedProperty (previously
        StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
      - (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
        semantics for initializing named own properties in object literal and
        public class fields, compiled from DefineNamedOwnProperty (previously
        StaNamedOwnProperty) and lowers to DefineNamedOwnIC
        (previously StoreOwnIC)
      - (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
        for keyed properties, only compiled from SetKeyedProperty(previously
        StaKeyedProperty) and lowers to KeyedStoreIC
      - (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
        semantics for initialization of private class fields and computed
        public class fields, compiled from DefineKeyedOwnProperty (previously
        StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
        KeyedDefineOwnIC).
      - (JS)StoreDataPropertyInLiteral ->
        (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
        initialization of keyed properties in object literals and static
        class initializers, compiled from DefineKeyedOwnPropertyInLiteral
        (previously StaDataPropertyInLiteral) and calls the
        DefineKeyedOwnPropertyInLiteral runtime function (previously
        DefineDataPropertyInLiteral).
      
      Runtime:
      - DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
        following the bytecode/opcodes change, this is used by
        DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
        for object and class literal initialization.
      - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
        it's just a simplified version of DefineDataPropertyInLiteral that
        does not update feedback or perform function name configuration.
        This is used by object spread and array literal creation. Since we
        are renaming DefineDataPropertyInLiteral to
        DefineKeyedOwnPropertyInLiteral, rename this simplified version with
        a `_Simple` suffix. We can consider merging it into
        DefineKeyedOwnPropertyInLiteral in the future. See
        https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
      - Other changes following the bytecode/IR changes
      
      IC:
      
      - StoreOwn -> DefineNamedOwn: used for initialization of named
        properties in object literals and named public class fields.
        - StoreOwnIC -> DefineNamedOwnIC
        - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
        - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
        - IsStoreOwn() -> IsDefineNamedOwn()
      - DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
        IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
        keyed defines so we don't need an extra generic predicate.
        - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
        - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
        - IsDefineOwn() -> IsDefineKeyedOwn()
        - IsDefineOwnIC() -> IsDefineKeyedOwnIC()
        - Removing IsKeyedDefineOwnIC() as its now a duplicate of
          IsDefineKeyedOwnIC()
      - KeyedDefineOwnIC -> DefineKeyedOwnIC,
        KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
        make the ordering of terms more consistent
      - IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
        DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
        removed since it's just a duplicate of this.
      - IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
        "keyed" part came from, but it's only used when DefineNamedOwnIC
        (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly
      
      Interpreter & compiler:
      - BytecodeArrayBuilder: following bytecode changes
          - StoreNamedProperty -> SetNamedProperty
        - StoreNamedOwnProperty -> DefineNamedOwnProperty
        - StoreKeyedProperty -> SetKeyedProperty
        - DefineKeyedProperty -> DefineKeyedOwnProperty
        - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
      - FeedbackSlotKind:
        - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
          consistent
        - kStoreOwnNamed -> kDefineNamedOwn: following the IC change
        - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
          used in StoreIC for set semantics
        - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
          in KeyedStoreIC for set semantics
        - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
          following the IC change
      - BytecodeGraphBuilder
        - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
          is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
          difference between SetNamedProperty and DefineNamedOwnProperty
          operations.
      
      Not changed:
      
      - StoreIC and KeyedStoreIC currently contain mixed logic for both Set
        and Define operations, and the paths are controlled by feedback. The
        plan is to refactor the hierarchy like this:
        ```
        - StoreIC
          - DefineNamedOwnIC
          - SetNamedIC (there could also be a NamedStoreIC if that's helpful)
          - KeyedStoreIC
            - SetKeyedIC
            - DefineKeyedOwnIC
            - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
            - StoreInArrayLiteralIC
          - ...
        ```
        StoreIC and KeyedStoreIC would then contain helpers shared by their
        subclasses, therefore it still makes sense to keep the word "Store"
        in their names since they would be generic base classes for both set
        and define operations.
      - The Lda and Sta prefixes of bytecodes not involving object properties
        (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
        property operations, and distinction between Set and Define might be
        less relevant or nonexistent for bytecodes not involving object
        properties. We could consider rename some of them in future patches
        if that's helpful though.
      
      Bug: v8:12548
      Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79409}
      0d1ffe30
  5. 21 Feb, 2022 2 commits
  6. 14 Feb, 2022 1 commit
  7. 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
  8. 20 Jan, 2022 1 commit
  9. 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
  10. 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
  11. 25 Nov, 2021 1 commit
  12. 22 Nov, 2021 1 commit
  13. 17 Nov, 2021 1 commit
  14. 08 Nov, 2021 1 commit
  15. 02 Nov, 2021 1 commit
    • Yang Guo's avatar
      Allow name collision when materializing scope object · 5395045f
      Yang Guo authored
      When materializing a scope object, we previously assumed that we will
      not have any name collisions. This is not correct e.g. when eval
      introduces an aliased local variable.
      
      This CL resolves this wrong assumption. The test case should not crash.
      It however fails as there is a bug in how debug-evaluate should resolve
      variables defined in eval.
      
      R=verwaest@chromium.org
      
      Fixed: chromium:1240962
      Bug: chromium:1264852
      Change-Id: I0e41e7905589735e25eff221376d09997ea99117
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250911
      Auto-Submit: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77649}
      5395045f
  16. 11 Oct, 2021 1 commit
  17. 16 Aug, 2021 1 commit
  18. 04 Aug, 2021 1 commit
  19. 02 Aug, 2021 1 commit
  20. 08 Jul, 2021 2 commits
    • Patrick Thier's avatar
      Reland "Reland "Reland "Improve error messages for property access on null/undefined""" · c0fd89c3
      Patrick Thier authored
      This is a reland of 819c3ae2
      
      Original change's description:
      > Reland "Reland "Improve error messages for property access on null/undefined""
      >
      > This is a reland of 8b18c5e6
      >
      > Original change's description:
      > > Reland "Improve error messages for property access on null/undefined"
      > >
      > > This is a reland of 24c626c1
      > >
      > > Original change's description:
      > > > Improve error messages for property access on null/undefined
      > > >
      > > > Only print the property name when accessing null/undefined if we can
      > > > convert it to a string without causing side effects.
      > > > If we can't, omit the property name in the error message.
      > > > This should avoid confusion when the key is an object with toString().
      > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > > Object]' anymore, which was misleading since the property accessed would
      > > > be 'a', but we can't evaluate the key without side effects.
      > > >
      > > > Bug: v8:11365
      > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#75250}
      > >
      > > Bug: v8:11365
      > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75571}
      >
      > Bug: v8:11365
      > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75604}
      
      Bug: v8:11365
      Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75645}
      c0fd89c3
    • Leszek Swirski's avatar
      Revert "Reland "Reland "Improve error messages for property access on null/undefined""" · 7ac7b72b
      Leszek Swirski authored
      This reverts commit 819c3ae2.
      
      Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
      
      Original change's description:
      > Reland "Reland "Improve error messages for property access on null/undefined""
      >
      > This is a reland of 8b18c5e6
      >
      > Original change's description:
      > > Reland "Improve error messages for property access on null/undefined"
      > >
      > > This is a reland of 24c626c1
      > >
      > > Original change's description:
      > > > Improve error messages for property access on null/undefined
      > > >
      > > > Only print the property name when accessing null/undefined if we can
      > > > convert it to a string without causing side effects.
      > > > If we can't, omit the property name in the error message.
      > > > This should avoid confusion when the key is an object with toString().
      > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > > Object]' anymore, which was misleading since the property accessed would
      > > > be 'a', but we can't evaluate the key without side effects.
      > > >
      > > > Bug: v8:11365
      > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#75250}
      > >
      > > Bug: v8:11365
      > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75571}
      >
      > Bug: v8:11365
      > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75604}
      
      Bug: v8:11365
      Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#75626}
      7ac7b72b
  21. 07 Jul, 2021 1 commit
    • Patrick Thier's avatar
      Reland "Reland "Improve error messages for property access on null/undefined"" · 819c3ae2
      Patrick Thier authored
      This is a reland of 8b18c5e6
      
      Original change's description:
      > Reland "Improve error messages for property access on null/undefined"
      >
      > This is a reland of 24c626c1
      >
      > Original change's description:
      > > Improve error messages for property access on null/undefined
      > >
      > > Only print the property name when accessing null/undefined if we can
      > > convert it to a string without causing side effects.
      > > If we can't, omit the property name in the error message.
      > > This should avoid confusion when the key is an object with toString().
      > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > Object]' anymore, which was misleading since the property accessed would
      > > be 'a', but we can't evaluate the key without side effects.
      > >
      > > Bug: v8:11365
      > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75250}
      >
      > Bug: v8:11365
      > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75571}
      
      Bug: v8:11365
      Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75604}
      819c3ae2
  22. 06 Jul, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "Reland "Improve error messages for property access on null/undefined"" · 94cd8b64
      Leszek Swirski authored
      This reverts commit 8b18c5e6.
      
      Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
      
      Original change's description:
      > Reland "Improve error messages for property access on null/undefined"
      >
      > This is a reland of 24c626c1
      >
      > Original change's description:
      > > Improve error messages for property access on null/undefined
      > >
      > > Only print the property name when accessing null/undefined if we can
      > > convert it to a string without causing side effects.
      > > If we can't, omit the property name in the error message.
      > > This should avoid confusion when the key is an object with toString().
      > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > Object]' anymore, which was misleading since the property accessed would
      > > be 'a', but we can't evaluate the key without side effects.
      > >
      > > Bug: v8:11365
      > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75250}
      >
      > Bug: v8:11365
      > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75571}
      
      Bug: v8:11365
      Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#75577}
      94cd8b64
    • Patrick Thier's avatar
      Reland "Improve error messages for property access on null/undefined" · 8b18c5e6
      Patrick Thier authored
      This is a reland of 24c626c1
      
      Original change's description:
      > Improve error messages for property access on null/undefined
      >
      > Only print the property name when accessing null/undefined if we can
      > convert it to a string without causing side effects.
      > If we can't, omit the property name in the error message.
      > This should avoid confusion when the key is an object with toString().
      > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > Object]' anymore, which was misleading since the property accessed would
      > be 'a', but we can't evaluate the key without side effects.
      >
      > Bug: v8:11365
      > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75250}
      
      Bug: v8:11365
      Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75571}
      8b18c5e6
  23. 21 Jun, 2021 1 commit
    • Bill Budge's avatar
      Revert "Improve error messages for property access on null/undefined" · b261213f
      Bill Budge authored
      This reverts commit 24c626c1.
      
      Reason for revert: Blocks V8 roll into Chromium (changed error messages cause tests to fail):
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/724109?
      
      Original change's description:
      > Improve error messages for property access on null/undefined
      >
      > Only print the property name when accessing null/undefined if we can
      > convert it to a string without causing side effects.
      > If we can't, omit the property name in the error message.
      > This should avoid confusion when the key is an object with toString().
      > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > Object]' anymore, which was misleading since the property accessed would
      > be 'a', but we can't evaluate the key without side effects.
      >
      > Bug: v8:11365
      > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75250}
      
      Bug: v8:11365
      Change-Id: Ic63f34033254f55b3871041633d84ea48586a75d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2977374
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75282}
      b261213f
  24. 18 Jun, 2021 1 commit
    • Patrick Thier's avatar
      Improve error messages for property access on null/undefined · 24c626c1
      Patrick Thier authored
      Only print the property name when accessing null/undefined if we can
      convert it to a string without causing side effects.
      If we can't, omit the property name in the error message.
      This should avoid confusion when the key is an object with toString().
      E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      Object]' anymore, which was misleading since the property accessed would
      be 'a', but we can't evaluate the key without side effects.
      
      Bug: v8:11365
      Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75250}
      24c626c1
  25. 17 Jun, 2021 1 commit
  26. 11 Jun, 2021 1 commit
  27. 01 Jun, 2021 2 commits
  28. 21 May, 2021 1 commit
    • Michael Achenbach's avatar
      [test] Run heavy tests sequentially · ee56a986
      Michael Achenbach authored
      This adds a new status file indicator "HEAVY" to mark tests with high
      resource demands. There will be other tests running in parallel,
      but only a limited number of other heavy tests. The limit is
      controlled with a new parameter --max-heavy-tests and defaults to 1.
      
      The change also marks a variety of tests as heavy that recently had
      flaky timeouts. Heavy also implies slow, hence heavy tests are
      executed at the beginning with a higher timeout like other slow tests.
      
      The implementation is encapsulated in the test-processor chain. A
      new processor buffers heavy tests in a queue and adds buffered tests
      only if other heavy tests have ended their computation.
      
      Bug: v8:5861
      Change-Id: I89648ad0030271a3a5af588ecc9c43285b728d6d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905767
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarLiviu Rau <liviurau@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74712}
      ee56a986
  29. 11 May, 2021 1 commit
  30. 10 May, 2021 1 commit
  31. 29 Apr, 2021 3 commits
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored
      The "Restart frame" feature was implemented as part of LiveEdit and
      primarily used to support LiveEdit of active functions, but that was
      previously disabled as part of https://crrev.com/c/2846892 because it's
      too brittle and causes crashes when using seemingly unrelated features.
      The "Restart frame" feature was also available as a context menu item
      separately in the DevTools front-end, but that was also already removed
      as part of https://crrev.com/c/2854681 earlier. So all uses are gone
      now.
      
      This change works by marking Debugger.restartFrame as deprecated and
      having it respond with a ServerError all the time. It thus allows us to
      remove a whole bunch of machinery that was essentially just put in
      various places to support the restart_fp_ magic. In particular the
      debugger no longer needs any machine specific builtins now.
      
      Bug: chromium:1195927
      Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
      Fixed: chromium:1203606
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
    • Wenyu Zhao's avatar
      [heap] Temporarily skip CodeRange and GC tests for TPH · 7e031690
      Wenyu Zhao authored
      * Will bring them back after TPH supports collection.
      
      Bug: v8:11641
      Change-Id: Ia170302ccaad9595663cf6bc618e725545a916e5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2858294
      Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74270}
      7e031690
    • Toon Verwaest's avatar
      [debug] Include Token::CLASS in class scopes and ContainsPosition · 00845abb
      Toon Verwaest authored
      While evaluating a class literal the containing function points to
      Token::CLASS. It may have pushed a context for that class that uses
      the range of the class scope. So far the class scope had a range that
      started after the class name or class token in case of anonymous
      classes. That means the source position of the function frame doesn't
      point to a position that is included in the active context range. This
      breaks the debugger because it relies on being able to find the
      matching parser scope for the active context by looking at the source
      position.
      
      The fix is two-fold:
      - extend the class scope source range to include Token::CLASS
      - update ScopeChainRetriever::ContainsPosition to include the start
        position of class scopes as a valid source position. We can't always
        include start due to arrow functions that don't have braces.
      
      Bug: chromium:1156498
      Change-Id: I9ec640c6326289dadcb154bb0a329ca6f8188f8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857957Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74268}
      00845abb
  32. 28 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Disallow LiveEdit of active frames. · 53fc4807
      Benedikt Meurer authored
      Previously we'd allow to replace the source of functions that are on the
      current execution stack under certain conditions, but this has resulted
      in an endless stream of bugs due to weird edge cases, and so we're now
      limiting LiveEdit to functions that don't have any activation (including
      not a suspended generator / async function activation).
      
      We might eventually add the ability to LiveEdit functions with
      activations and have them "upgrade upon next invocation", but that
      doesn't seem to be an extremely important use case right now.
      
      Fixed: chromium:1195927
      Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74249}
      53fc4807
  33. 27 Apr, 2021 1 commit
  34. 26 Apr, 2021 1 commit