r347205 - [FileManager] getFile(open=true) after getFile(open=false) should open the file.

[Sam McCall via cfe-commits]

(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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190123/15187a57/attachment.html>