summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Basic/FileManagerTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* ASTReader: Bypass overridden files when reading PCHsDuncan P. N. Exon Smith2019-08-301-0/+50
| | | | | | | | | | | | | | | | | | | | | If contents of a file that is part of a PCM are overridden when reading it, but weren't overridden when the PCM was being built, the ASTReader will emit an error. Now it creates a separate FileEntry for recovery, bypassing the overridden content instead of discarding it. The pre-existing testcase clang/test/PCH/remap-file-from-pch.cpp confirms that the new recovery method works correctly. This resolves a long-standing FIXME to avoid hypothetically invalidating another precompiled module that's already using the overridden contents. This also removes ContentCache-related API that would be unsafe to use across `CompilerInstance`s in an implicit modules build. This helps to unblock us sinking it from SourceManager into FileManager in the future, which would allow us to delete `InMemoryModuleCache`. https://reviews.llvm.org/D66710 llvm-svn: 370546
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-11/+11
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* Fix Windows branch of FileManagerTest changesHarlan Haskins2019-08-011-1/+1
| | | | llvm-svn: 367622
* Fix use-after-move in ClangBasicTestsHarlan Haskins2019-08-011-1/+1
| | | | llvm-svn: 367620
* [clang] Adopt new FileManager error-returning APIsHarlan Haskins2019-08-011-6/+16
| | | | | | | 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
* [clang] Adopt llvm::ErrorOr in FileManager methodsHarlan Haskins2019-08-011-37/+45
| | | | | | | 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
* [FileSystemStatCache] Update test for new FileSystemStatCache APIHarlan Haskins2019-04-161-5/+6
| | | | | | | | | | | | | | 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
* Replace clang::FileData with llvm::vfs::StatusHarlan Haskins2019-03-051-12/+11
| | | | | | | | | | | | | | | | 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
* [clang][test] Fix FileManagerTest.getFileDontOpenRealPath for WindowsJan Korous2019-02-181-6/+10
| | | | llvm-svn: 354296
* Reland "[clang][FileManager] fillRealPathName even if we aren't opening the ↵Jan Korous2019-02-181-0/+29
| | | | | | | | | file" This reverts commit e2bb3121fd4ab5b01f9ec1d2e3e9877db9c6a54c. + fixed test for Windows llvm-svn: 354291
* Revert r354075 "[clang][FileManager] fillRealPathName even if we aren't ↵Reid Kleckner2019-02-151-14/+0
| | | | | | | | opening the file" The new test doesn't pass on Windows. llvm-svn: 354169
* [clang][FileManager] fillRealPathName even if we aren't opening the fileJan Korous2019-02-141-0/+14
| | | | | | | | | | | | | 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
* [FileManager] Revert r347205 to avoid PCH file-descriptor leak.Sam McCall2019-01-241-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Remove stat cache chaining as it's no longer needed after PTH support has beenAlex Lorenz2018-12-211-19/+10
| | | | | | | | | | | | | 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
* [tests] Fix the FileManagerTest getVirtualFile test on WindowsStella Stamenova2018-12-071-8/+20
| | | | | | | | | | | | 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
* Expect mixed path separators in FileManagerTest when resolving paths on Win32Matthew Voss2018-11-301-1/+1
| | | | llvm-svn: 348028
* [clang] Fix rL348006 for windowsKadir Cetinkaya2018-11-301-1/+8
| | | | llvm-svn: 348015
* [clang] Fill RealPathName for virtual files.Kadir Cetinkaya2018-11-301-7/+18
| | | | | | | | | | | | | | | 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
* Ensure FileManagerTest expects "\\" as path separator on Windows platformsMatthew Voss2018-11-201-0/+4
| | | | llvm-svn: 347284
* [FileManager] getFile(open=true) after getFile(open=false) should open the file.Sam McCall2018-11-191-0/+27
| | | | | | | | | | | | | | | | | | | 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
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-5/+5
| | | | | | | | | | | | | | | | | | | 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
* [Test commit] Fix a spelling error.Jiading Gai2018-07-241-1/+1
| | | | llvm-svn: 337807
* IWYU for llvm-config.h in clang. See r331124 for details.Nico Weber2018-04-301-1/+0
| | | | llvm-svn: 331177
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-271-7/+7
| | | | | | | | | | | 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
* Use VFS operations in FileManager::makeAbsolutePath.Ilya Biryukov2017-08-021-0/+27
| | | | | | | | | | | | | | 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
* FileManager: mark virtual file entries as valid entriesErik Verbruggen2017-03-281-2/+50
| | | | | | | | | | | | | | | | | | 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
* Turn FileManager DirectoryEntry::Name from raw pointer to StringRef (NFC)Mehdi Amini2016-10-111-8/+8
| | | | llvm-svn: 283856
* Store FileEntry::Filename as a StringRef instead of raw pointer (NFC)Mehdi Amini2016-10-101-2/+2
| | | | llvm-svn: 283815
* Add missing include.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230910
* [cleanup] Re-sort the #include lines using llvm/utils/sort_includes.pyChandler Carruth2015-01-141-1/+1
| | | | | | | No functionality changed, this is a purely mechanical cleanup to ensure the #include order remains consistent across the project. llvm-svn: 225975
* unique_ptr-ify FileSystemStatCache::setNextStatCacheDavid Blaikie2014-08-111-13/+22
| | | | | | | | | | And in the process, discover that FileManager::removeStatCache had a double-delete when removing an element from the middle of the list (at the beginning or the end of the list, there was no problem) and add a unit test to exercise the code path (which successfully crashed when run (with modifications to match the old API) without this patch applied) llvm-svn: 215388
* Update unit test for signature change.Benjamin Kramer2014-07-081-2/+3
| | | | llvm-svn: 212545
* [C++11] Use 'nullptr'. Unittests edition.Craig Topper2014-06-081-17/+17
| | | | llvm-svn: 210423
* Remove the last remaining llvm/Config/config.h includesAlp Toker2014-06-041-1/+1
| | | | | | | | | | | | 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. llvm-svn: 210145
* Check for LLVM_ON_WIN32 instead of _WIN32.Hans Wennborg2014-03-121-4/+5
| | | | | | This is a follow-up to r203624 to address Anton's comment. llvm-svn: 203668
* Reapply fixed "Honour 'use-external-names' in FileManager"Ben Langmuir2014-02-281-3/+6
| | | | | | | | | | | | | | | | 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. llvm-svn: 202539
* Revert "Honour 'use-external-names' in FileManager"Ben Langmuir2014-02-271-1/+0
| | | | | | Revert r202442, which broke the buildbots. llvm-svn: 202443
* Honour 'use-external-names' in FileManagerBen Langmuir2014-02-271-0/+1
| | | | | | | | 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. llvm-svn: 202442
* Recommit virtual file systemBen Langmuir2014-02-201-1/+1
| | | | | | | | | | | 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. llvm-svn: 201818
* Reverting the virtual file system implementation, because it triggers an ↵Juergen Ributzka2014-02-201-1/+1
| | | | | | | | | | assertion in our internal build bots. This reverts commits 201618, 201635, 201636, 201639, 201685, 201691, and 201696. llvm-svn: 201755
* Initial implementation of virtual file systemBen Langmuir2014-02-191-1/+1
| | | | | | | | | | | | This adds the minimum virtual file system support to start migrating FileManager onto the VFS. Originally discussed here: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035188.html Differential Revision: http://llvm-reviews.chandlerc.com/D2745 llvm-svn: 201618
* Use llvm::sys::fs::UniqueID for windows and unix.Rafael Espindola2013-08-011-13/+10
| | | | | | | | | | | | | | | | | | | 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. llvm-svn: 187619
* Fix handling of "clang c:foo"Rafael Espindola2013-07-291-0/+17
| | | | | | | | | | | | | 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! llvm-svn: 187359
* Extend stat query APIs to explicitly specify if the query is forArgyrios Kyrtzidis2012-12-111-1/+1
| | | | | | | | | | 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. llvm-svn: 169831
* Sort the #include lines for unittests/...Chandler Carruth2012-12-041-2/+1
| | | | | | I've tried to place sensible headers at the top as main-module headers. llvm-svn: 169243
* unittests/Basic/FileManagerTest.cpp: Suppress warnings on gcc.NAKAMURA Takumi2011-09-231-1/+2
| | | | llvm-svn: 140364
* unittests/Basic/FileManagerTest.cpp: Unbreak Win32, mingw and msvc.NAKAMURA Takumi2011-06-241-3/+3
| | | | | | | 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. llvm-svn: 133794
* Moves FileManagerTest.cpp to unittests/Basic such that the unit testZhanyong Wan2011-02-151-0/+222
directory structure matches the library structure. Reviewed by jyasskin. llvm-svn: 125600
OpenPOWER on IntegriCloud