Abstract serialization: TableGen the (de)serialization code for Types.
authorJohn McCall <rjmccall@apple.com>
Sat, 14 Dec 2019 02:54:44 +0000 (21:54 -0500)
committerJohn McCall <rjmccall@apple.com>
Sat, 14 Dec 2019 05:17:01 +0000 (00:17 -0500)
commitd505e57cc273750541ec8bbce2065b8b87c99ad6
tree5a96e0ced43a51381773c434c065bb2c9cd3f3a2
parent6404bd236240639d4986d1ee634ded4bc81d8bd8
Abstract serialization: TableGen the (de)serialization code for Types.

The basic technical design here is that we have three levels
of readers and writers:

- At the lowest level, there's a `Basic{Reader,Writer}` that knows
  how to emit the basic structures of the AST.  CRTP allows this to
  be metaprogrammed so that the client only needs to support a handful
  of primitive types (e.g. `uint64_t` and `IdentifierInfo*`) and more
  complicated "inline" structures such as `DeclarationName` can just
  be emitted in terms of those primitives.

  In Clang's binary-serialization code, these are
  `ASTRecord{Reader,Writer}`.  For now, a large number of basic
  structures are still emitted explicitly by code on those classes
  rather than by either TableGen or CRTP metaprogramming, but I
  expect to move more of these over.

- In the middle, there's a `Property{Reader,Writer}` which is
  responsible for processing the properties of a larger object.  The
  object-level reader/writer asks the property-level reader/writer to
  project out a particular property, yielding a basic reader/writer
  which will be used to read/write the property's value, like so:

  ```
    propertyWriter.find("count").writeUInt32(node->getCount());
  ```

  Clang's binary-serialization code ignores this level (it uses
  the basic reader/writer as the property reader/writer and has the
  projection methods just return `*this`) and simply relies on the
  roperties being read/written in a stable order.

- At the highest level, there's an object reader/writer (e.g.
  `Type{Reader,Writer}` which emits a logical object with properties.
  Think of this as writing something like a JSON dictionary literal.

I haven't introduced support for bitcode abbreviations yet --- it
turns out that there aren't any operative abbreviations for types
besides the QualType one --- but I do have some ideas of how they
should work.  At any rate, they'll be necessary in order to handle
statements.

I'm sorry for not disentangling the patches that added basic and type
reader/writers; I made some effort to, but I ran out of energy after
disentangling a number of other patches from the work.

Negligible impact on module size, time to build a set of about 20
fairly large modules, or time to read a few declarations out of them.
13 files changed:
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/AbstractBasicReader.h [new file with mode: 0644]
clang/include/clang/AST/AbstractBasicWriter.h [new file with mode: 0644]
clang/include/clang/AST/AbstractTypeReader.h [new file with mode: 0644]
clang/include/clang/AST/AbstractTypeWriter.h [new file with mode: 0644]
clang/include/clang/AST/CMakeLists.txt
clang/include/clang/AST/Type.h
clang/include/clang/AST/TypeProperties.td [new file with mode: 0644]
clang/include/clang/Serialization/ASTReader.h
clang/include/clang/Serialization/ASTWriter.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/utils/TableGen/TableGen.cpp