[cfe-dev] FileEntry::IsValid and FileEntry::UID

Vladimir Voskresensky - Oracle via cfe-dev cfe-dev at lists.llvm.org
Tue Oct 6 09:31:05 PDT 2015


Hello,

I'd like to have better understanding for FileEntry's UID and IsValid fields.
.. Or there is just a bug in FileManager::getVirtualFile
so blockshould have as the last statement extra line
--------
if (getStatValue(InterndFileName, Data, true, nullptr) == 0) {
  <skip>
  UFE->IsValid = true;
}
---------

I expected constness of FileEntry.UID, but I face the following problem:
When I initialize preprocessor with RemappedFileBuffers (i.e. for some physical 
files I prepare in-memory content replacements), then InitializeFileRemapping 
for each such remapped ones calls FileMgr.getVirtualFile
which creates FileEntry and assign UID
UFE.UID = NextFileUID++;
and leave IsValid as false
Let's say I had two remapped buffers, in this case UID "zero" and "one" are 
assigned.
Name field has absolute file path, i.e. "/my/file/path/file.h"
As soon as files can be stated, they are also registered in UniqueRealFiles by 
UniqueID

Then when preprocessor meets my files during Include Directives handling it calls
FileManager::getFile
When included Filename param is not normalized, but looks like 
"/my/file/path/../path/file.h" it fails to find it in SeenFileEntries, calls 
Stat, detects UniqueID and finds it in
UniqueRealFiles.
But as soon as UFE.IsValid() returns false then
if (UFE.isValid()) { // Already have an entry with this inode, return it.
fails
}

So,
UID is modified to some random next values in the bottom part of getFile():
UFE.UID = NextFileUID++;
followed by
UFE.IsValid = true;
which freeze UID changes.

Is it expected behavior? Then what is the logic behind it?
Or just a bug?

Thanks,
Vladimir.



More information about the cfe-dev mailing list