(Email is better than IRC if that's OK - I don't know this code that well so it takes me a while).
Thanks, that's definitely interesting and not what I expected. I thought every call sequence r347205 changed the behavior of would have resulted in two calls to getStatValue(). I guess the "pch"/"main" output is printed before the corresponding lines in run.sh? Weird that we don't get any output from building the PCH, but I don't know well how PCH builds work. > It looks like FS->getCurrentWorkingDirectory() is set yet FileSystemOpts.WorkingDir.empty() is also true. Is that expected? I think so. The FileManager and the VFS each have their own concept of working directory, I guess for historical reasons. Making use of the VFS one but not the FileManager one seems reasonable. So the weirdness is that FileSystemStatCache::get() is returning true (i.e. file doesn't exist), when the file does exist. Possibilities: 1) we're serving this result from the FileSystemStatCache (and maybe it's being poisoned in a PCH-related way somehow). Except as far as I can tell, FileSystemStatCache is always null (FileManager::setStateCache has no callers). 2) the FS.openFileForRead call failed (ultimately ::open, if FS is the real FS) 3) the OwnedFile->status() call failed (ultimately ::fstat) 4) I'm misreading the code somehow Could you find out which of these is going on? Either running in a debugger or adding some similar printfs to FileSystemStatCache::get() should be doable. I'm also going to try to work out how the patch could have affected this, but new vs correct much easier for me to compare than new vs old...
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
