Closed jan-auer closed 5 years ago
@willglynn Before I finish this up, wondering if you have reservations against the general approach of splitting the streams up into an explicit TPI and IPI stream rather than merging them magically internally.
Unforunately, it's not possible to know which stream to use by just looking at the numbers. That means, that it would be necessary to look in both streams and then prefer one result over the other. However, at the declaration side, it is always clear which stream the index refers to, hence the differentiation.
@willglynn All feedback should be addressed now.
I hope that the type defs don't make it odd to use TypeIndex
now.
This PR exposes the ID stream (IPI).
The TPI and IPI streams share the same structure, but they contain different records. Most importantly, the type of index used indicates whether a type lives in the IPI or the TPI. In
microsoft-pdb
this is eitherCV_typ_t
for types, orCV_ItemId
for ids. Of course, both areu32
.To create a clear interface that avoids confusion, identifiers are clearly separated into
TypeIndex(u32)
andIdIndex(u32)
. Since now the id stream needs the same root struct, iterator and finder, this is abstracted intoItemInformation<I>
,ItemIter<I>
andItemFinder<I>
, whereI
is the index being used. On top of that, there are type definitions to simplify the handling of such types:type Type<'t> = Item<'t, TypeIndex>
, etc.Apart from some renaming for consistency, usage stays mostly the same.
Unrelated, this PR contains two more fixes. They can be moved into separate PRs if desired: