1. 01 Oct, 2021 4 commits
  2. 30 Sep, 2021 28 commits
  3. 29 Sep, 2021 8 commits
    • Seth Brenith's avatar
      [torque] Get rid of @generatePrint annotation · 267b067b
      Seth Brenith authored
      I'm trying to remove annotations and make behavior more consistent. For
      @generatePrint, there are two options: either generate printers for
      every extern class, or never generate printers for extern classes. This
      change implements the option of always generating printers. Classes that
      require custom printing can easily hide the generated printer by using
      DECL_PRINTER. This causes the generated file
      gen/torque-generated/objects-printer.cc to grow to 1600 lines, including
      many functions that are never used, but I think the consistency benefit
      outweighs a little more compilation time on one file. This change also
      removes custom printers in cases where the generated printer includes
      all of the same content.
      
      If folks would prefer the option to never generate printers, I'm open to
      doing that instead. I like the notion that generating more code could
      reduce the friction of adding new classes and thereby encourage people
      to define precise types rather than using FixedArrays, but the current
      implementation of generated printers is limited, and many printers have
      been customized to show the data that matters the most. Unlike verifiers
      and body descriptors, there are no correctness or safety concerns with
      hand-written printers.
      
      Some bugs showed up once we start generating printers for everything,
      and this change fixes them:
      - Printers incorrectly included ungettable fields like padding
      - Printers called getters which might be hidden by hand-written classes
      - The generated getter for Map::instance_type used
        ReadField<InstanceType>, which is not an arithmetic type since it's an
        enum
      
      One more tiny drive-by fix: added a missing newline in the printers for
      JSMap and JSSet.
      
      Bug: v8:7793
      Change-Id: Ib9e9575fbcb57879935ff18bf4db49fe276d2966
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172190Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77152}
      267b067b
    • Seth Brenith's avatar
      [torque] Remove unused field offset macros · d5625e35
      Seth Brenith authored
      Nobody uses the generated *_FIELDS macros anymore, so we can remove
      them. I also renamed the generated file to represent its content better.
      
      Bug: v8:7793
      Change-Id: I49ab39e363d6961e7210cd67018b6fb83b65a162
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192191Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77151}
      d5625e35
    • Junliang Yan's avatar
      ppc/s390: [liftoff][arm] Add explicit stack check for large frames · 5a505fc0
      Junliang Yan authored
      Port edc349db
      
      Bug: v8:11235
      Change-Id: I53538b1a18d778c4580683d300bc380ee1041c40
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194874Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#77150}
      5a505fc0
    • Clemens Backes's avatar
      [asm] Fix importing monkey-patched objects · 4b6ee115
      Clemens Backes authored
      This fixes a long-standing TODO to disallow importing receivers that
      have "toString" or "valueOf" patched. Calling those methods could have
      observable side effects, so allowing that would require bigger
      refactorings to ensure that we only call each such function exactly once
      per import, and in the right order.
      Since this use case is rare, we just forbid importing such receivers.
      
      R=jkummerow@chromium.org
      
      Bug: chromium:1248677
      Change-Id: I99bbd7db950ec3c7ac9cc1f59e8c476688e7d7b6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190475Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77149}
      4b6ee115
    • Junliang Yan's avatar
      ppc: [liftoff] implement AtomicExch and AtomicCmpExch · 3600aabf
      Junliang Yan authored
      Change-Id: Ida66b9c42cfb9bd5b59a83188a2dfa0d602d4036
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192427Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#77148}
      3600aabf
    • Milad Fa's avatar
      PPC/s390: Create Instance Type for Class Constructors · 7245d2c1
      Milad Fa authored
      Port: 1cd7a582
      
      Original Commit Message:
      
      Class Constructors are special, because they are callable but [[Call]]
      raises an exception. Instead of checking if a JS function is a class
      constructor for every JS function call, this CL adds a new instance
      type for class constructors.
      This way we can use a fast instance type range check for the common
      case, and only check for class constructors in the uncommon case were
      a class constructor is called and when we need to raise an exception.
      
      Change-Id: I578fde90d00d1e80cf36ba28205ce9bfe6830afb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192422Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#77147}
      7245d2c1
    • Maya Lekova's avatar
      Revert "[torque] Get rid of @noVerifier annotation" · 8679a4e1
      Maya Lekova authored
      This reverts commit 94958172.
      
      Reason for revert: Breaks arm/arm64 ports, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/30120/blamelist
      
      Original change's description:
      > [torque] Get rid of @noVerifier annotation
      >
      > As one small step toward reducing annotations, I propose that all
      > classes get generated verifiers unless they've opted out of C++ class
      > generation via @doNotGenerateCppClass, and that generated verifiers
      > always verify every Torque-defined field. If a generated verifier is
      > incorrect, such as for JSFunction or DataHandler, we can just avoid
      > calling it and hand-code the verification.
      >
      > Bug: v8:7793
      > Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#77145}
      
      Bug: v8:7793
      Change-Id: I56da8a9726d23470e927be1be5e7bcede1399861
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194262
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77146}
      8679a4e1
    • Seth Brenith's avatar
      [torque] Get rid of @noVerifier annotation · 94958172
      Seth Brenith authored
      As one small step toward reducing annotations, I propose that all
      classes get generated verifiers unless they've opted out of C++ class
      generation via @doNotGenerateCppClass, and that generated verifiers
      always verify every Torque-defined field. If a generated verifier is
      incorrect, such as for JSFunction or DataHandler, we can just avoid
      calling it and hand-code the verification.
      
      Bug: v8:7793
      Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77145}
      94958172