1. 24 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add a way to specify that a class field is optional · c2d419a3
      Seth Brenith authored
      Currently, some ScopeInfo fields are defined as indexed fields with a
      length of either one or zero, because the field might be present or it
      might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 ,
      this strategy is not sustainable and we need a better way to represent
      optional fields so that we don't have to pass zero when accessing their
      only element. This change is a proposal to fix that problem.
      
      Syntax:
      
      I'm proposing using a question mark because TypeScript does, and Torque
      syntax looks somewhat like TypeScript. I don't feel strongly about this
      though, and I'm open to other suggestions.
        field_name?[condition_expression]: FieldType;
      
      Internal Torque compiler representation:
      
      Internally, I've updated the Torque compiler to still treat these fields
      as indexed, but with an extra flag saying they're optional. When getting
      a LocationReference for a field access expression on an optional field,
      Torque produces a Slice like it would for any other indexed field and
      subsequently calls AtIndex(0) to get a Reference.
      
      AtIndex can crash the process if the index is out of bounds (which is
      good), so some other parts of the Torque compiler need minor adjustments
      so that it doesn't take references to optional fields unless it actually
      needs them.
      
      Initialization:
      
      This proposal doesn't include any changes to initialization logic, so an
      optional field can still be initialized using '...' and an iterator.
      Perhaps we could introduce an Optional<T> struct for prettier
      initialization in a future change.
      
      Bug: v8:7793
      Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73018}
      c2d419a3
  2. 09 Feb, 2021 1 commit
  3. 03 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add @relaxedRead annotation · cffd8bc8
      Seth Brenith authored
      When generating getters, Torque needs to decide whether to perform a
      normal or relaxed load. Thus far, it has used the somewhat non-obvious
      logic that any indexed field with tagged non-smi data gets relaxed
      loads. This change adds a new annotation @relaxedRead to be consistent
      with the existing @relaxedWrite annotation. I added @relaxedRead
      annotations on any field that previously had this automatic behavior and
      whose getter is called, except for those in ScopeInfo because I'm
      relatively confident that it doesn't need relaxed access.
      
      Bug: v8:7793
      Change-Id: I9987eea13760b967f1b8a3189b69742e55140c30
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2600113
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72499}
      cffd8bc8
  4. 11 Nov, 2020 1 commit
  5. 22 Oct, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Strict verification of abstract types · 50d474a2
      Seth Brenith authored
      Originally, the Torque-generated verifier for a field with type
      Undefined|Zero|NonNullForeign would check `f.IsUndefined() || f.IsZero()
      || f.IsNonNullForeign()`. At some point, we changed Torque so that it
      now generates the much weaker `f.IsOddball() || f.IsSmi() ||
      f.IsForeign()`. This change returns the verifiers to their initial
      precision. Mostly we can use the names of abstract types to build up the
      correct type check expression, but a few abstract types like
      PodArrayOfWasmValueType have no way that we can tell them apart from
      their parent type at runtime. It would be confusing to have a function
      Object::IsPodArrayOfWasmValueType which actually just checks whether the
      object is a ByteArray, so this change introduces a new annotation which
      allows abstract type declarations to state that they should use their
      parent type during verification.
      
      This change also adds new test cases to help avoid future regressions of
      this logic.
      
      Bug: v8:7793
      Change-Id: Ie5046d742fd45e0e0f6c2ba387d909e9f2ac6df1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469960Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70698}
      50d474a2
  6. 05 Oct, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Generate shorter code for indexed field accesses · 73a8eded
      Seth Brenith authored
      Currently, when accessing a field that doesn't have a constant offset,
      Torque emits code to compute each preceding indexed field's length and
      add them all together. This works, but such code can get super long if a
      class has many indexed fields, and especially if the length expressions
      of some indexed fields refer to other indexed fields. We'd like the
      output of the new C++ backend to be short enough to go in inline headers
      which will be included in many compilation units.
      
      This change attempts to reorganize the code so that the computation of
      each length expression can only be emitted exactly once. This only
      shortens the generated C++ code; the resulting TurboFan output should be
      identical. There are two main parts:
      1. For each indexed field, we already generate a macro that can get a
         Slice referring to that field. Update these macros to not use the dot
         operator on that field. Using the dot operator on the predecessor
         field is allowed.
      2. Update the dot operator for indexed fields to emit a call to the
         macro from step 1.
      
      This sort of reverses the dependency added by the previous change
      https://crrev.com/c/2429566 : rather than the slice macros depending on
      the dot operator, this change makes the dot operator depend on the slice
      macros.
      
      The overall torque_generated directory shrinks by under 1% with this
      change, but the runtime_macros.cc file (which should eventually become
      inline headers) shrinks by 24%. More to the point, this change keeps
      runtime_macros.cc from ballooning out of control when we add a
      work-in-progress Torque definition for ScopeInfo
      ( https://crrev.com/c/2357758 ).
      
      Bug: v8:7793
      Change-Id: I989dda9c3666f1a49281fef03acb35baebb5b63a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432070Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70325}
      73a8eded
  7. 27 Jul, 2020 1 commit
  8. 10 Jul, 2020 1 commit
  9. 06 May, 2020 1 commit
  10. 01 May, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] avoid ambiguity if a catch catches from other handlers · 7e7b24eb
      Tobias Tebbi authored
      Torque desugars try-catch/label constructs with several handlers
      into nested try structures, with the first handler ending-up
      innermost. So currently, if you write
      
      try {
      ...
      } label Foo {
        Throw(...);
      } catch (e) {
      
      }
      
      The catch will catch the preceding Throw in another handler.
      This is different from how multiple try-catch handlers are done in
      languages like Java, where throwing from a preceding catch handler
      is not caught by a later one. To avoid this possible ambiguity, this
      CL prohibits this pattern, enforcing that a catch handler comes first,
      before any other label-handler attached to the same try.
      This way, a catch handler never catches from any other handler on the
      same try, since they have to come later.
      
      Bug: v8:7793
      Change-Id: I943f14b2393d307c4254a3fc3a78f236dbcf86df
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169098
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67516}
      7e7b24eb
  11. 17 Apr, 2020 1 commit
  12. 18 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] add const references and disallow const class field writes · d7e02ea4
      Tobias Tebbi authored
      - Allow type expression for abstract type supertypes.
        For consistency, and ease of implementation, also allow this for enums.
      - Allow subtyping of structs. This requires changing all places where we
        checked for struct types and instead check if we have a subtype of a
        struct type.
      - This allows defining two subtypes of the Reference<T> struct for
        mutable and constant references. Mutable references are a subtype of
        constant references.
      - &T desugars to MutableReference<T>
        const &T desugars to ConstReference<T>
      - A const field of a class produces a constant reference.
        A const field of a mutable reference to a struct is const.
        A mutable field of a const reference to a struct is const.
      - It is possible to assign a new struct value to a mutable reference to
        a struct, even if the struct contains const fields. This is analogous
        to allowing assignments of let-bound structs with constant fields.
      
      Not in this CL:
      - A notion of const slices.
      - Applying const to appropriate class fields.
      
      Bug: v8:7793
      Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66759}
      d7e02ea4
  13. 02 Jan, 2020 1 commit
  14. 23 Dec, 2019 1 commit
  15. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] multiple arrays in one object · 59e8d45a
      Tobias Tebbi authored
      This allows the definition of classes with several arrays and ports
      SmallOrderedHashTable subclasses to Torque as an example, including
      the existing CSA allocation functions for them.
      
      Overview of changes:
      - Introduce ResidueClass to encapsulate the modulo-arithmetic
        necessary to do alignment checks.
      - Add MachineOperatorReducer to the CSA pipeline to address now
        missing CSA ad-hoc constant folding that got blocked by a
        temporary phi.
      - Allow assignments to references to structs. This is needed to
        initialize the data_table part of SmallOrderedHashMap.
      - Make the NumberLiteralExpression AST-node store a double instead
        of a string. This is necessary to detect arrays with constant size
        used for padding.
      - Turn offsets into base::Optional<size_t> to ensure we don't use
        an invalid or statically unknown offset.
      - Remove CreateFieldReferenceInstruction since it doesn't work for
        complex offset computations and the logic can be expressed better
        in ImplementationVisitor.
      - Validate alignment of structs embedded in classes.
      
      Bug: v8:10004 v8:7793
      Change-Id: Ifa414b42278e572a0c577bf9da3d37f80771a258
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958011
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65538}
      59e8d45a
  16. 12 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] allow expressions for array lengths · 6b663123
      Tobias Tebbi authored
      This allows arbitrary expressions to specify the length of an array.
      These expressions get access to globally declared things and the
      preceding fields of the current object.
      Unfortunately, this breaks generated C++ runtime code, so as a
      workaround, I special-case expressions that are just an identifier
      and handle them as before. We might want to support more cases there
      in the future, probably also with special-casing since having a full
      C++ back-end for Torque is infeasible.
      
      Bug: v8:10004 v8:7793
      
      Change-Id: I0d5d1200c0e727766beed7bfb2d43a8abb9cacf0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1942610
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65427}
      6b663123
  17. 06 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Add bitfield declarations · 57074692
      Seth Brenith authored
      This change is the first part of adding Torque support for a "bitfield
      struct", which represents a set of bitfields packed together into an
      integer value. With this change, Torque can generate the list of
      BitField template specializations that allow runtime code to use the
      bitfield values. The flags used in SharedFunctionInfo are converted to
      Torque to exercise this functionality. Bitfield values are not yet
      accessible directly from Torque code.
      
      Bug: v8:7793
      Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65371}
      57074692
  18. 31 Oct, 2019 1 commit
  19. 29 Oct, 2019 1 commit
  20. 24 Oct, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] introduce generic abstract types · 5bba6680
      Tobias Tebbi authored
      This expands the existing mechanism for generic structs to also cover
      abstract types. This involves:
      - Moving the SpecializationKey from StructType to Type, so that it's
        also available to AbstractType.
      - Moving the generic parameters out of the StructDeclaration AST node
        and using the existing GenericDeclaration AST node for generic structs
        and abstract types too.
      - The GenericStructType declarable gets generalized to GenericType.
      
      This will be useful for defining a Weak<T> type for weak pointers.
      
      Bug: v8:7793
      Change-Id: I183b3a038a143cf0ae5888150104c4a025fd736c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859623
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64533}
      5bba6680
  21. 22 Oct, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] replace name mangling with unique numbering · 419b4e7e
      Tobias Tebbi authored
      Name mangling is hard to get right and not easy to read.
      This CL replaces the remaining name mangling of types and generics
      with simpler names that are not always unique, but then fixes them
      up by appending a unique counter.
      
      For struct types, this required an @export annotation since we use some
      struct types in CSA.
      
      Drive-by-fixes:
      
      - Overwrite the copy constructor of Type to clear the list
      of alias names when creating a new type.
      
      - Change the existing append-a-number scheme to have different
        counters for each name. This the number of changed names when adding
        something and is more readable.
      
      Bug: v8:7793
      Change-Id: Ied11ea1a251130f4562ddc0d81967368349e0bf6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866650
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64449}
      419b4e7e
  22. 11 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Generate instance types · 8c7ae314
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit
      
      Changes from the design doc:
      - Changed to use 'class' declarations rather than 'type' declarations
        for things that need instance types but whose layout is not known to
        Torque. These declarations end with a semicolon rather than having a
        full set of methods and fields surrounded by {}. If the class's name
        should not be treated as a class name in generated output (because
        it's actually a template, or doesn't exist at all), we use the
        standard 'generates' clause to declare the most appropriate C++ class.
      - Removed @instanceTypeName.
      - @highestInstanceType became @highestInstanceTypeWithinParentClassRange
        to indicate a semantic change: it no longer denotes the highest
        instance type globally, but only within the range of values for its
        immediate parent class. This lets us use it for Oddball, which is
        expected to be the highest primitive type.
      - Added new abstract classes JSCustomElementsObject and JSSpecialObject
        to help with some range checks.
      - Added @lowestInstanceTypeWithinParentClassRange so we can move the new
        classes JSCustomElementsObject and JSSpecialObject to the beginning of
        the JSObject range. This seems like the least-brittle way to establish
        ranges that also include JSProxy (and these ranges are verified with
        static assertions in instance-type.h).
      - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
      - Renamed @instanceTypeFlags to @reserveBitsInInstanceType.
      
      This change introduces the new annotations and adds the ability for
      Torque to assign instance types that satisfy those annotations. Torque
      now emits two new macros:
      - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
        InstanceType enumeration
      - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
        parts of INSTANCE_TYPE_LIST
      
      The design document mentions a couple of other macro lists that could
      easily be replaced, but I'd like to defer those to a subsequent checkin
      because this one is already pretty large.
      
      Bug: v8:7793
      Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64258}
      8c7ae314
  23. 20 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Allow single-param annotations in AnnotationSet · fb453dd4
      Seth Brenith authored
      Extend the order-independent annotation parsing logic to include the
      following forms:
        @foo                // bare annotation (already supported)
        @foo(0x70)          // decimal literal
        @foo(HI)            // identifier
        @foo("hello there") // quoted string
      This is obviously still pretty far from annotations in other languages,
      which usually support arbitrary expressions and multiple parameters, but
      I think it's sufficient to cover a pretty good variety of usages. The
      existing class-field annotations @if and @ifnot are reimplemented in the
      new style, meaning they could now appear in any order relative to other
      annotations on the same field (and can be repeated, though I doubt it
      would be of much use to anybody).
      
      Change-Id: I97b7c0c9a541ca3126b5ae3a2484688b04dda9f4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1754947
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63285}
      fb453dd4
  24. 06 Aug, 2019 1 commit
  25. 26 Jul, 2019 1 commit
  26. 23 Jul, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Add Generic Structs · 1d9a5d88
      Georg Schmid authored
      This CL introduces generic Torque structs. Generics are grounded early in the Torque compilation pipeline, meaning that every instantiation of a generic struct with concrete types will be turned into a distinct StructType.
      
      As an example, consider a Tuple of types T1, T2:
      
        struct Tuple<T1: type, T2: type> {
          const fst: T1;
          const snd: T2;
        }
      
      which can be manipulated using generic macros, such as
      
        macro Swap<T1: type, T2: type>(tuple: Tuple<T1, T2>): Tuple<T2, T1> {
          return Tuple<T2, T1>{fst: tuple.snd, snd: tuple.fst};
        }
      
      Currently there is no type inference for struct instantiation sites, so type arguments have to be provided explicitly:
      
        const intptrAndSmi = Tuple<intptr, Smi>{fst: 1, snd: 2};
      
      R=sigurds@chromium.org, tebbi@chromium.org
      
      Change-Id: I43111561cbe53144db473dc844a478045644ef6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714868
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62878}
      1d9a5d88
  27. 14 Jun, 2019 3 commits
  28. 11 Jun, 2019 1 commit
  29. 06 Jun, 2019 1 commit
    • Simon Zünd's avatar
      [torque] Add lint errors for unused variable and label bindings · 0e53739c
      Simon Zünd authored
      This CL adds lint errors when 'let' bindings, arguments and labels
      are not used. Note that errors for 'const' bindings will be added
      later.
      
      In cases where arguments are actually needed to match the signature,
      the warning can be silenced by prefixing identifiers with "_". This
      might be needed for generic specializations or builtins called from
      TurboFan. Trying to use a variable or label that was marked with
      "_" results in a compilation error.
      
      Implicit arguments are not linted. They are implemented using exact
      string matching. Prefixing an implicit argument with "_" in a callee
      would break all callers as the names would no longer match.
      
      Drive-by: Fix all new lint errors in the existing Torque code.
      
      Bug: v8:7793
      Change-Id: I68b3c59c76b956e9f88709e9388a40a19546ce52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645092
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62027}
      0e53739c
  30. 05 Jun, 2019 1 commit
  31. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  32. 20 May, 2019 1 commit
  33. 16 May, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Move Map layout definition to Torque · 15a7e04e
      Seth Brenith authored
      This commit attempts to change as little behavior as possible, but it
      does require reordering the fields within Map to abide by Torque rules
      specifying that strong and weak fields must be in separate sections.
      
      Also includes some Torque compiler updates:
      - Allow enums (types extending from integral types) as class fields
      - Rename @ifdef to @if and add @ifnot for inverse checks
      - Allow void fields in class declarations, which take up no space and
        emit no accessors
      
      Bug: v8:8952
      Change-Id: I1de6f34c1b15ed87d718666a05176980a218e97c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1480919
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61588}
      15a7e04e
  34. 14 May, 2019 1 commit
  35. 13 May, 2019 3 commits
  36. 10 May, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Automatically generate verifier functions · e483fb27
      Seth Brenith authored
      This change generates functions that verify the things that Torque knows
      about objects and their fields. We still must implement each verifier
      function in objects-debug.cc, but we can call into the generated code to
      verify that field types match their Torque definitions. If no additional
      verification is required, we can use the macro USE_TORQUE_VERIFIER as a
      shorthand for a verifier that calls the corresponding generated
      function.
      
      A new annotation @noVerifier can be applied to both class and field
      definitions, to prevent generating verification code. This allows fully
      customized verification for complicated cases like
      JSFunction::prototype_or_initial_map, which might not exist at all, and
      JSObject::elements, which might be a one pointer filler map.
      
      Because Factory::InitializeJSObjectFromMap fills new objects with
      undefined values, and many verifiers need to deal with partially-
      initialized objects, the generated verifiers allow undefined values on
      every class deriving from JSObject. In cases where stricter checks were
      previously performed, they are kept in objects-debug.cc.
      
      Bug: v8:7793
      Change-Id: I84034efadca89ba0aceddf92e886ffbfaa4c23fa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594042
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61422}
      e483fb27