This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210145 91177308-0d34-0410-b5e6-96231b3b80d8
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
On windows, c:foo is a valid file path, but stat fails on just "c:". This
causes a problem for clang since its file manager wants to cache data about
the parent directory.
There are refactorings to be done in here, but this gives clang the correct
behavior and testing first.
Patch by Yunzhong Gao!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187359 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
LLVM_ON_WIN32 is defined in llvm/Config/config.h.
IMO, it might be enough with _WIN32 in most cases, LLVM_ON_xxx could be deprecated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133794 91177308-0d34-0410-b5e6-96231b3b80d8
Craig Topper