After HeaderSearchInfo is recovered in
PCHReader::ReadSourceManagerBlock(), we actually have used some UIDs
(recorded by NumHeaderInfos). But at this time the NextFileUID in
FileManager is still 0. Call to FileManager::getFile() could use that
FileUID for a different file than the header in HeaderSearch. Would
this inconsistency cause problems?
After reading some more code, my understanding is that all file source
locations are then preloaded and FileManager is restored to the
Yes, we preload all file source locations. We may be able to decrease PCH load times slightly by not preloading them, but it's not something that ever came up in a profile so I doubt it's important.
I think we have to preload them to bind the correct UIDs to the header
files? Otherwise FileManager may use UIDs for different files than the
files in HeaderSearchInfo.
This probably means another level of mapping between PCH UIDs and the current UIDs, if we want to avoid preloading.