Was r202442
There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
compileModule. This was hidden in some cases by the fact I didn't
clear the module cache in the test.
Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202539 91177308-0d34-0410-b5e6-96231b3b80d8
Pass through the externally-visible names that we got from the VFS down
to FileManager, and test that this is the name showing up in __FILE__,
diagnostics, and debug information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202442 91177308-0d34-0410-b5e6-96231b3b80d8
Previously reverted in r201755 due to causing an assertion failure.
I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201818 91177308-0d34-0410-b5e6-96231b3b80d8
This unifies the unix and windows versions of FileManager::UniqueDirContainer
and FileManager::UniqueFileContainer by using UniqueID.
We cannot just replace "struct stat" with llvm::sys::fs::file_status, since we
want to be able to construct fake ones, and file_status has different members
on unix and windows.
What the patch does is:
* Record only the information that clang is actually using.
* Use llvm::sys::fs::status instead of stat and fstat.
* Use llvm::sys::fs::UniqueID
* Delete the old windows versions of UniqueDirContainer and
UniqueFileContainer since the "unix" one now works on windows too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187619 91177308-0d34-0410-b5e6-96231b3b80d8
a file or directory, allowing just a stat call if a file descriptor
is not needed.
Doing just 'stat' is faster than 'open/fstat/close'.
This has the effect of cutting down system time for validating the input files of a PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169831 91177308-0d34-0410-b5e6-96231b3b80d8
followed by an open for every source file we open, probe the file system with
'open' and then do an fstat when it succeeds. open+fstat is faster than
stat+open because the kernel only has to perform the string->inode mapping
once. Presumably it gets faster the deeper in your filesystem a lookup
happens.
For -Eonly on cocoa.h, this reduces system time from 0.042s to 0.039s on
my machine, a 7.7% speedup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120066 91177308-0d34-0410-b5e6-96231b3b80d8
pointer that is passed down through the APIs, and make
FileSystemStatCache::get be the one that filters out
directory lookups that hit files. This also paves the
way to have stat queries be able to return opened files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120060 91177308-0d34-0410-b5e6-96231b3b80d8
Craig Topper