1. 10 Nov, 2020 1 commit
    • Daniel Clark's avatar
      Plumb import assertions through SourceTextModuleDescriptor's ModuleRequestMap · ea0ccc7e
      Daniel Clark authored
      This change plumbs import assertions from SourceTextModuleDescriptor's
      ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest
      type, where previously there had been only the specifier.
      
      SourceTextModuleDescriptor::module_map now deduplicates module requests
      using the specifier and the import assertions.  Continuing to use the
      specifier alone would cause a loss of information in the event that
      a module imports from the same specifier multiple times using different
      sets of assertions.  Failing to deduplicate at all would result in
      multiple requests for statements like `import {a,b,c} from "foo.js"`,
      which would be a potential performance issue.  See design doc at
      https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY
      for more detail on this decision.
      
      v8::internal::ModuleRequest holds the assertions as an array of the form
      [key1, value1, position1, key2, value2, assertion2, ...].  However the
      parser still needs to use a map, since duplicate assertion keys need to
      be detected at parse time.  A follow-up  change will ensure that
      assertions are sorted using a proper lexicographic sort.
      
      Bug: v8:10958
      Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71066}
      ea0ccc7e
  2. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296