Previously we had logic in CVTypeDumper that would try to build up a list of types that had been encountered while dumping a type stream. All of this logic was embedded in the CVTypeDumper class, so it was hard to re-use anywhere else. In practice, the idea of visiting a list of types and then using the resulting information for something will be useful for more than just dumping types. My immediate need for this is to have a separate "compact" dump output format, where all we dump is a type's name, leaf kind, and type index, all on a single line. This doesn't really belong in CVTypeDumper since it has so much additional logic to dump nested fields etc, so I wanted to make a separate compact dumper. But in order to do this, I would need to re-implement all of this name logic. So this patch:
- Creates the notion of a TypeDatabase, which stores type indices and type record data
- Creates a TypeDatabaseVisitor which builds up a TypeDatabase while iterating over a type stream.
- Updates CVTypeDumper to use TypeDatabaseVisitor, by simply sticking a TypeDatabaseVisitor into the callback pipeline and having CVTypeDumper read the same instance of TypeDatabase that TypeDatabaseVisitor writes to.
In the future, we can make TypeDatabase more complicated, such as storing hash values, allowing lookup by various types, and searching, and this can be the general purpose type database used for all type based operations (for example in implementing the DIA SDK in terms of native APIs)
Should these use the same .def file trick used in so many other places with large tables like this?