1. 31 Jul, 2020 1 commit
  2. 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
  3. 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
  4. 31 Oct, 2019 1 commit
  5. 29 Oct, 2019 1 commit
  6. 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
  7. 13 Sep, 2019 1 commit
  8. 10 Sep, 2019 1 commit
  9. 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
  10. 14 Jun, 2019 3 commits
  11. 05 Jun, 2019 1 commit
  12. 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
  13. 07 May, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Make torque declarations order independent · 70678d53
      Sigurd Schneider authored
      Torque semantic analysis is now a four-stage process:
      
       1. The TypeDeclarationVisitor introduces a TypeAlias for every
          TypeDeclaration* (or derived) in the Torque source, but does
          not process the TypeDeclaration* itself.
       2. All aliases are resolved in a dependency respecting manner.
          This CL also changes struct member resolution to happen at
          this point already. Types for classes are created, but their
          members are not resolved to allow classes to mutually reference
          each other in their field types.
       3. 'value' declarations (macros, etc.) are processed.
       4. Members of classes are processed.
      
      Bug: v8:7793
      Change-Id: I46108555a5cdf30df03c5d4399ec786ee6cc6df4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584319
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61264}
      70678d53
  14. 06 May, 2019 1 commit
    • Simon Zünd's avatar
      [torque] Better SourcePositions for declarables · 9b30bdb4
      Simon Zünd authored
      This CL improves SourcePosition support inside the Torque compiler.
      It starts with the parser, where the SourcePosition of the
      MatchedInput now encompasses all tokens, not just the first one.
      
      Second, AST nodes can now be created with an explicit source position.
      This can be used to forward the "all encompassing" source position
      via MatchedInput -> ParseResultIterator to AST nodes.
      
      Third, declarables are extended to hold two different SourcePositions:
        - One represents the whole declarable. For a macro this would
          inlcude the body as well as the signature.
        - The other is the SourcePosition of the identifying part of a
          declarable. In most cases this is the name. For the rest this
          will stay invalid.
      
      R=sigurds@chromium.org, tebbi@chromium.org
      
      Bug: v8:7793
      Change-Id: I509f83aeef7a040d0ea6363b5b7c31ff1b11f47b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591600
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61234}
      9b30bdb4
  15. 11 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] add references to HeapObject fields. · a9a1a3bb
      Tobias Tebbi authored
      This adds references to HeapObject fields to Torque.
      The syntax is based on Rust (which is essentially C pointer syntax).
      
      The type &T is a reference to T (which must be a scalar type for now).
      We can create references from field access expressions, using the
      addressof(&) operator:
        &obj.fieldname
      To read or assign a reference, we use the dereference(*) operator:
        *someref = *otherref
      
      This CL also uses references internally normal class field accesses,
      but only if there is no overload for field accessor functions.
      This allows to have overloaded field accessors for a subtype like
      FastJSArray. However, there is a change in behavior in that an
      operator ".fieldname" will stop reference creation and will therefore
      also stop write access to a class field of the same name. That's why
      this CL had to add a write overload ".length=" for FastJSArray.
      
      References desugar to a pair of a tagged HeapObject pointer and an
      untagged offset into this HeapObject. On the CSA-side, they are
      represented by the C++ struct
      
      struct TorqueReference {
        TNode<HeapObject> object;
        TNode<IntPtrT> offset;
      };
      
      Bug: v8:7793
      Change-Id: Ica6468d47847bd68fb6b85f731cf8fbe142fa401
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557151
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60780}
      a9a1a3bb
  16. 04 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] named arguments for constructors · e87e3b1f
      Tobias Tebbi authored
      This changes the syntax for constructing structs and classes to explicitly
      mention the fieldnames, similar to JavaScript object literals.
      The fields still have to be listed in the same order as in the struct/class
      declaration.
      As in Javascript, {foo: foo} can be abbreviated as {foo}.
      
      Example:
      
      macro NewJSArray(implicit context: Context)(
          map: Map, elements: FixedArrayBase): JSArray {
        return new JSArray{
          map,
          properties_or_hash: kEmptyFixedArray,
          elements,
          length: elements.length
        };
      }
      
      Drive-by cleanup: Make struct and class constructors follow the same pattern
                        in the parser and the AST.
      
      Bug: v8:9018 v8:7793
      Change-Id: I22ff7f68270e4f406aa80731a709d41ea52f52bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1551999Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60622}
      e87e3b1f
  17. 12 Mar, 2019 1 commit
  18. 04 Mar, 2019 1 commit
  19. 26 Feb, 2019 2 commits
  20. 18 Dec, 2018 1 commit
  21. 24 Jul, 2018 1 commit
  22. 20 Jul, 2018 1 commit