1. 29 Sep, 2021 1 commit
    • 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
  2. 21 Jul, 2021 1 commit
  3. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored
      This CL is pretty mechanical; I just iterated through some Torque
      classes making the following changes:
      
      - Use @generateCppClass if it seems easy to
      - Use @generatePrint if the existing printer doesn't do anything special
      - Fix up any imprecise field types
      
      It also includes two minor changes to implementation-visitor:
      
      - Add a new -inl.h file with the things needed for
        torque-generated/class-definitions-tq.cc so we don't need to keep
        changing the compiler when we add @generateCppClass.
      - Avoid emitting incorrect accessors for ExternalPointers. This isn't
        strictly necessary for correctness, as the accessors defined in C++
        already hide the ones inherited from generated code, but it makes me
        feel safer.
      
      Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985
  4. 11 Nov, 2019 1 commit
  5. 01 May, 2019 1 commit
  6. 09 Jan, 2019 1 commit
  7. 08 Jan, 2019 1 commit