Fix Windows branch of FileManagerTest changes

llvm-svn: 367622

Fix use-after-move in ClangBasicTests

llvm-svn: 367620

[clang] Adopt new FileManager error-returning APIs

Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.

Signed-off-by: Harlan

[clang] Adopt new FileManager error-returning APIs

Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.

Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367616

show more ...

[clang] Adopt llvm::ErrorOr in FileManager methods

Previously, the FileManager would use NULL returns to signify whether a file existed, but that doesn’t cover permissions issues or anything else th

[clang] Adopt llvm::ErrorOr in FileManager methods

Previously, the FileManager would use NULL returns to signify whether a file existed, but that doesn’t cover permissions issues or anything else that might occur while trying to stat or read a file. Instead, convert getFile and getDirectory into returning llvm::ErrorOr

Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367615

show more ...

[FileSystemStatCache] Update test for new FileSystemStatCache API

Summary: Update this test to return std::error_code instead of LookupResult.

Reviewers: arphaman

Subscribers: dexonsmith, cfe-comm

[FileSystemStatCache] Update test for new FileSystemStatCache API

Summary: Update this test to return std::error_code instead of LookupResult.

Reviewers: arphaman

Subscribers: dexonsmith, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D60786

llvm-svn: 358511

show more ...

Replace clang::FileData with llvm::vfs::Status

Summary:
FileData was only ever used as a container for the values in
llvm::vfs::Status, so they might as well be consolidated.

The `InPCH` member was

Replace clang::FileData with llvm::vfs::Status

Summary:
FileData was only ever used as a container for the values in
llvm::vfs::Status, so they might as well be consolidated.

The `InPCH` member was also always set to false, and unused.

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58924

llvm-svn: 355368

show more ...

[clang][test] Fix FileManagerTest.getFileDontOpenRealPath for Windows

llvm-svn: 354296

Reland "[clang][FileManager] fillRealPathName even if we aren't opening the file"

This reverts commit e2bb3121fd4ab5b01f9ec1d2e3e9877db9c6a54c.
+ fixed test for Windows

llvm-svn: 354291

Revert r354075 "[clang][FileManager] fillRealPathName even if we aren't opening the file"

The new test doesn't pass on Windows.

llvm-svn: 354169

[clang][FileManager] fillRealPathName even if we aren't opening the file

The pathname wasn't previously filled when the getFile() method was called with openFile = false.
We are caching FileEntry-s

[clang][FileManager] fillRealPathName even if we aren't opening the file

The pathname wasn't previously filled when the getFile() method was called with openFile = false.
We are caching FileEntry-s in ParsedAST::Includes in clangd and this caused the problem.

This fixes an internal test failure in clangd - ClangdTests.GoToInclude.All

rdar://47536127

Differential Revision: https://reviews.llvm.org/D58213

llvm-svn: 354075

show more ...

[FileManager] Revert r347205 to avoid PCH file-descriptor leak.

Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the

[FileManager] Revert r347205 to avoid PCH file-descriptor leak.

Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.

Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225

Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).

So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.

Reviewers: bkramer, thakis

Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D57165

llvm-svn: 352079

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Remove stat cache chaining as it's no longer needed after PTH support has been
removed

Stat cache chaining was implemented for a StatListener in the PTH writer so that
it could write out the stat in

Remove stat cache chaining as it's no longer needed after PTH support has been
removed

Stat cache chaining was implemented for a StatListener in the PTH writer so that
it could write out the stat information to PTH. r348266 removed support for PTH,
and it doesn't seem like there are other uses of stat cache chaining. We can
remove the chaining support.

Differential Revision: https://reviews.llvm.org/D55455

llvm-svn: 349942

show more ...

[tests] Fix the FileManagerTest getVirtualFile test on Windows

Summary: The test passes on Windows only when it is executed on the C: drive. If the build and tests run on a different drive, the test

[tests] Fix the FileManagerTest getVirtualFile test on Windows

Summary: The test passes on Windows only when it is executed on the C: drive. If the build and tests run on a different drive, the test is currently failing.

Reviewers: kadircet, asmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D55451

llvm-svn: 348665

show more ...

Expect mixed path separators in FileManagerTest when resolving paths on Win32

llvm-svn: 348028

[clang] Fix rL348006 for windows

llvm-svn: 348015

[clang] Fill RealPathName for virtual files.

Summary:
Absolute path information for virtual files were missing even if we
have already stat'd the files. This patch puts that information for virtual

[clang] Fill RealPathName for virtual files.

Summary:
Absolute path information for virtual files were missing even if we
have already stat'd the files. This patch puts that information for virtual
files that can succesffully be stat'd.

Reviewers: ilya-biryukov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D55054

llvm-svn: 348006

show more ...

Ensure FileManagerTest expects "\\" as path separator on Windows platforms

llvm-svn: 347284

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

Summary:
Old behavior is to just return the cached entry regardless of opened-ness.
That feels buggy (though I guess

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

Summary:
Old behavior is to just return the cached entry regardless of opened-ness.
That feels buggy (though I guess nobody ever actually needed this).

This came up in the context of clangd+clang-tidy integration: we're
going to getFile(open=false) to replay preprocessor actions obscured by
the preamble, but the compilation may subsequently getFile(open=true)
for non-preamble includes.

Reviewers: ilya-biryukov

Subscribers: ioeric, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D54691

llvm-svn: 347205

show more ...

Lift VFS from clang to llvm (NFC)

This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang

Lift VFS from clang to llvm (NFC)

This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.

RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html

Differential revision: https://reviews.llvm.org/D52783

llvm-svn: 344140

show more ...

[Test commit] Fix a spelling error.

llvm-svn: 337807

IWYU for llvm-config.h in clang. See r331124 for details.

llvm-svn: 331177

s/LLVM_ON_WIN32/_WIN32/, clang

LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of

s/LLVM_ON_WIN32/_WIN32/, clang

LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.

See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.

llvm-svn: 331069

show more ...

Use VFS operations in FileManager::makeAbsolutePath.

Summary: It used to call into llvm::sys::fs::make_absolute.

Reviewers: akyrtzi, erikjv, bkramer, krasimir, klimek

Reviewed By: klimek

Subscrib

Use VFS operations in FileManager::makeAbsolutePath.

Summary: It used to call into llvm::sys::fs::make_absolute.

Reviewers: akyrtzi, erikjv, bkramer, krasimir, klimek

Reviewed By: klimek

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D36155

llvm-svn: 309795

show more ...

FileManager: mark virtual file entries as valid entries

The getVirtualFile method would create entries for e.g. libclang's
CXUnsavedFile but not mark them as valid. The effect is that a lookup
throu

FileManager: mark virtual file entries as valid entries

The getVirtualFile method would create entries for e.g. libclang's
CXUnsavedFile but not mark them as valid. The effect is that a lookup
through getFile where the file name is not exactly matching the virtual
file (e.g. through mixing slashes and backslashes on Windows) would
result in a normal file "lookup", and re-using the file entry found
by using the UniqueID, and overwrite the file entry fields. Because the
lookup involves opening the file, and moving it into the file entry, the
file is now open. The SourceManager keys its buffers on the UniqueID
(which is still the same), so it will find an already loaded buffer.
Because only the loading a buffer from disk will close the file, the
FileEntry will hold on to an open file for as long as the FileManager
is around. As the FileManager will only get destroyed at a reparse,
you can't safe to the "leaked" and locked file on Windows.

llvm-svn: 298905

show more ...