aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Basic/VirtualFileSystem.cpp
AgeCommit message (Collapse)AuthorFilesLines
2018-10-10Lift VFS from clang to llvm (NFC)Jonas Devlieghere1-2142/+0
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
2018-09-26llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song1-2/+1
Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
2018-09-24[VFS] Use llvm::StringMap instead of std::map. NFCEric Liu1-1/+1
llvm-svn: 342889
2018-09-14[VFS] vfs::directory_iterator yields path and file type instead of full StatusSam McCall1-44/+37
Summary: Most callers I can find are using only `getName()`. Type is used by the recursive iterator. Now we don't have to call stat() on every listed file (on most platforms). Exceptions are e.g. Solaris where readdir() doesn't include type information. On those platforms we'll still stat() - see D51918. The result is significantly faster (stat() can be slow). My motivation: this may allow us to improve clang IO on large TUs with long include search paths. Caching readdir() results may allow us to skip many stat() and open() operations on nonexistent files. Reviewers: bkramer Subscribers: fedor.sergeev, cfe-commits Differential Revision: https://reviews.llvm.org/D51921 llvm-svn: 342232
2018-09-05[VFS] Cache the current working directory for the real FS.Eric Liu1-2/+16
Reviewers: sammccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51641 llvm-svn: 341455
2018-09-04Adding HardLink Support to VirtualFileSystem.Ilya Biryukov1-49/+119
Summary: Added support of creating a hardlink from one file to another file. After a hardlink is added between two files, both file will have the same: 1. UniqueID (inode) 2. Size 3. Buffer This will bring replay of compilation closer to the actual compilation. There are instances where clang checks for the UniqueID of the file/header to be loaded which leads to a different behavior during replay as all files have different UniqueIDs. Patch by Utkarsh Saxena! Reviewers: ilya-biryukov Reviewed By: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51359 llvm-svn: 341366
2018-08-08[NFC][VFS] Fix typos in comments.Volodymyr Sapsai1-2/+2
llvm-svn: 339215
2018-08-07[VFS] Unify iteration code for VFSFromYamlDirIterImpl, NFC intended.Volodymyr Sapsai1-19/+10
First and subsequent iteration steps are similar, capture this similarity. Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50118 llvm-svn: 339199
2018-08-07[VFS] Emit an error when entry at root level uses a relative path.Volodymyr Sapsai1-3/+15
Entries with only a filename prevent us from building a file system tree and cause the assertion > Assertion failed: (NewParentE && "Parent entry must exist"), function uniqueOverlayTree, file clang/lib/Basic/VirtualFileSystem.cpp, line 1303. Entries with a relative path are simply not discoverable during header search. rdar://problem/28990865 Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49518 llvm-svn: 339164
2018-08-06[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi1-14/+51
requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. An indirect impact of this change is that a -Wnonportable-include-path warning is now emitted in test PCH/case-insensitive-include.c. This is because the real path of the included file (with the wrong case) was not available previously, whereas it is now. Reviewers: malaperle, ilya-biryukov, bkramer Reviewed By: ilya-biryukov Subscribers: eric_niebler, malaperle, omtcyfz, hokein, bkramer, ilya-biryukov, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 339063
2018-07-26Revert r338057 "[VirtualFileSystem] InMemoryFileSystem::status: Return a ↵Reid Kleckner1-51/+14
Status with the requested name" This broke clang/test/PCH/case-insensitive-include.c on Windows. llvm-svn: 338084
2018-07-26[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi1-14/+51
requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. Reviewers: malaperle, ilya-biryukov, bkramer Subscribers: cfe-commits, ioeric, ilya-biryukov, bkramer, hokein, omtcyfz Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 338057
2018-07-24Revert "[VFS] Cleanups to VFS interfaces."Jordan Rupprecht1-19/+18
This reverts commit r337834 due to test failures. llvm-svn: 337850
2018-07-24[VFS] Cleanups to VFS interfaces.Sam McCall1-18/+19
Summary: - add comments clarifying semantics - Status::copyWithNewName(Status, Name) --> instance method - Status::copyWithNewName(fs::file_status, Name) --> constructor (it's not a copy) - File::getName() -> getRealPath(), reflecting its actual behavior/function and stop returning status().getName() in the base class (callers can do this fallback if they want to, it complicates the contracts). This is mostly NFC, but the behavior of File::getName() affects FileManager's FileEntry::tryGetRealPathName(), which now fails in more cases: - non-real file cases - real-file cases where the underlying vfs::File was opened in a way that doesn't call realpath(). (In these cases we don't know a distinct real name, so in principle it seems OK) Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49724 llvm-svn: 337834
2018-07-11Revert "[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with ↵Eric Liu1-56/+16
the requested name" This reverts commit r336807. This breaks users of ClangTool::mapVirtualFile. Will try to investigate a fix. See also the discussion on https://reviews.llvm.org/D48903 llvm-svn: 336831
2018-07-11[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi1-16/+56
requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. In general, I guess it's good if InMemoryFileSystem works as much as possible like RealFileSystem. Doing so made the FileEntry::RealPathName value (assigned in FileManager::getFile) wrong when using the InMemoryFileSystem. That's because it assumes that vfs::File::getName will always return the real path. I changed to to use FileSystem::getRealPath instead. Subscribers: ilya-biryukov, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 336807
2018-06-07[FileSystem] Split up the OpenFlags enumeration.Zachary Turner1-1/+2
This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
2018-05-24[VFS] Implement getRealPath in InMemoryFileSystem.Eric Liu1-0/+13
Reviewers: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47262 llvm-svn: 333172
2018-05-18[VFS] Implement getRealPath for OverlayFileSystem.Eric Liu1-0/+9
Reviewers: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47060 llvm-svn: 332717
2018-05-17Add vfs::FileSystem::getRealPathEric Liu1-0/+13
Summary: And change `FileManager::getCanonicalName` to use getRealPath. Reviewers: bkramer Reviewed By: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46942 llvm-svn: 332590
2018-05-09Remove \brief commands from doxygen comments.Adrian Prantl1-14/+14
This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-04-27s/LLVM_ON_WIN32/_WIN32/, clangNico Weber1-2/+2
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
2018-04-04Fixes errors with FS iterators caused by https://reviews.llvm.org/D44960Max Moroz1-6/+8
Summary: In https://reviews.llvm.org/D44960, file status check is executed every time a real file system directory iterator is constructed or incremented, and emits an error code. This change list fixes the errors in VirtualFileSystem caused by https://reviews.llvm.org/D44960. Patch by Yuke Liao (@liaoyuke). Reviewers: vsk, pcc, zturner, liaoyuke Reviewed By: vsk Subscribers: mgrang, cfe-commits Differential Revision: https://reviews.llvm.org/D45178 llvm-svn: 329223
2018-03-28[Basic] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-97/+180
other minor fixes (NFC). llvm-svn: 328735
2018-03-27[clang] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang1-2/+2
r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. llvm-svn: 328636
2017-11-16[VirtualFileSystem] Support creating directories then adding files insideBen Hamilton1-3/+9
Summary: In https://reviews.llvm.org/D39572 , I added support for specifying `Type` when invoking `InMemoryFileSystem::addFile()`. However, I didn't account for the fact that when `Type` is `directory_file`, we need to construct an `InMemoryDirectory`, not an `InMemoryFile`, or else clients cannot create files inside that directory. This diff fixes the bug and adds a test. Test Plan: New test added. Ran test with: % make -j12 check-clang-tools Reviewers: bkramer, hokein Reviewed By: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40140 llvm-svn: 318445
2017-11-09[VirtualFileSystem] InMemoryFileSystem::addFile(): Type and PermsBen Hamilton1-13/+27
Summary: This implements a FIXME in InMemoryFileSystem::addFile(), allowing clients to specify User, Group, Type, and/or Perms when creating a file in an in-memory filesystem. New tests included. Ran tests with: % ninja BasicTests && ./tools/clang/unittests/Basic/BasicTests Fixes PR#35172 (https://bugs.llvm.org/show_bug.cgi?id=35172) Reviewers: bkramer, hokein Reviewed By: bkramer, hokein Subscribers: alexfh Differential Revision: https://reviews.llvm.org/D39572 llvm-svn: 317800
2017-10-10Support: Have directory_iterator::status() return ↵Peter Collingbourne1-2/+2
FindFirstFileEx/FindNextFile results on Windows. This allows clients to avoid an unnecessary fs::status() call on each directory entry. Because the information returned by FindFirstFileEx is a subset of the information returned by a regular status() call, I needed to extract a base class from file_status that contains only that information. On my machine, this reduces the time required to enumerate a ThinLTO cache directory containing 520k files from almost 4 minutes to less than 2 seconds. Differential Revision: https://reviews.llvm.org/D38716 llvm-svn: 315378
2017-07-20[vfs] Assert that the status is known in equivalent().Benjamin Kramer1-0/+1
Otherwise we'd silently compare uninitialized data. llvm-svn: 308604
2017-03-14Reapply [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka1-5/+2
Modified the tests to accept any iteration order, to run only on Unix, and added additional error reporting to investigate SystemZ bot issue. The VFS directory iterator and recursive directory iterator behave differently from the LLVM counterparts. Once the VFS iterators hit a broken symlink they immediately abort. The LLVM counterparts don't stat entries unless they have to descend into the next directory, which allows to recover from this issue by clearing the error code and skipping to the next entry. This change adds similar behavior to the VFS iterators. There should be no change in current behavior in the current CLANG source base, because all clients have loop exit conditions that also check the error code. This fixes rdar://problem/30934619. Differential Revision: https://reviews.llvm.org/D30768 llvm-svn: 297693
2017-03-11Revert "Reapply [VFS] Ignore broken symlinks in the directory iterator."Juergen Ributzka1-2/+5
Still broken on Windows and SystemZ bot ... sorry for the noise. llvm-svn: 297533
2017-03-10Reapply [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka1-5/+2
Modified the tests to accept any iteration order. The VFS directory iterator and recursive directory iterator behave differently from the LLVM counterparts. Once the VFS iterators hit a broken symlink they immediately abort. The LLVM counterparts allow to recover from this issue by clearing the error code and skipping to the next entry. This change adds the same functionality to the VFS iterators. There should be no change in current behavior in the current CLANG source base, because all clients have loop exit conditions that also check the error code. This fixes rdar://problem/30934619. Differential Revision: https://reviews.llvm.org/D30768 llvm-svn: 297528
2017-03-10Revert r297510 "[VFS] Ignore broken symlinks in the directory iterator."Juergen Ributzka1-2/+5
The tests are failing on one of the bots. llvm-svn: 297517
2017-03-10[VFS] Remove the Path variable from RealFSDirIter. NFC.Juergen Ributzka1-3/+1
This variable is set, but never used. llvm-svn: 297511
2017-03-10[VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka1-5/+2
The VFS directory iterator and recursive directory iterator behave differently from the LLVM counterparts. Once the VFS iterators hit a broken symlink they immediately abort. The LLVM counterparts allow to recover from this issue by clearing the error code and skipping to the next entry. This change adds the same functionality to the VFS iterators. There should be no change in current behavior in the current CLANG source base, because all clients have loop exit conditions that also check the error code. This fixes rdar://problem/30934619. Differential Revision: https://reviews.llvm.org/D30768 llvm-svn: 297510
2017-01-24Replace use of chdir with llvm::sys::fs::set_current_pathPavel Labath1-12/+1
NFCI llvm-svn: 292914
2016-12-22[CrashReproducer] Add support for merging -ivfsoverlayBruno Cardoso Lopes1-3/+44
Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs overlay provided by the crash reproducer. This is the last missing piece to allow crash reproducers to fully work with user frameworks; when combined with headermaps, it allows clang to find additional frameworks. rdar://problem/27913709 llvm-svn: 290326
2016-11-09[VFS] Replace TimeValue usage with std::chronoPavel Labath1-13/+14
Summary: NFCI Reviewers: benlangmuir, zturner Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25948 llvm-svn: 286356
2016-08-12Reapply [VFS] Skip non existent files from the VFS treeBruno Cardoso Lopes1-8/+26
Reapply r278457 with test fixed to not abouse fs case sensitivity. When the VFS uses a YAML file, the real file path for a virtual file is described in the "external-contents" field. Example: ... { 'type': 'file', 'name': 'a.h', 'external-contents': '/a/b/c/a.h' } Currently, when parsing umbrella directories, we use vfs::recursive_directory_iterator to gather the header files to generate the equivalent modules for. If the external contents for a header does not exist, we currently are unable to build a module, since the VFS vfs::recursive_directory_iterator will fail when it finds an entry without a reliable real path. Since the YAML file could be prepared ahead of time and shared among different compiler invocations, an entry might not yet have a reliable path in 'external-contents', breaking the iteration. Give the VFS the capability to skip such entries whenever 'ignore-non-existent-contents' property is set in the YAML file. rdar://problem/27531549 llvm-svn: 278543
2016-08-12Revert "[VFS] Skip non existent files from the VFS tree"Bruno Cardoso Lopes1-26/+8
Breaking bots: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/27281/ This reverts commit r278457. llvm-svn: 278459
2016-08-12[VFS] Skip non existent files from the VFS treeBruno Cardoso Lopes1-8/+26
When the VFS uses a YAML file, the real file path for a virtual file is described in the "external-contents" field. Example: ... { 'type': 'file', 'name': 'a.h', 'external-contents': '/a/b/c/a.h' } Currently, when parsing umbrella directories, we use vfs::recursive_directory_iterator to gather the header files to generate the equivalent modules for. If the external contents for a header does not exist, we currently are unable to build a module, since the VFS vfs::recursive_directory_iterator will fail when it finds an entry without a reliable real path. Since the YAML file could be prepared ahead of time and shared among different compiler invocations, an entry might not yet have a reliable path in 'external-contents', breaking the iteration. Give the VFS the capability to skip such entries whenever 'ignore-non-existent-contents' property is set in the YAML file. rdar://problem/27531549 llvm-svn: 278457
2016-08-12[VFS] Add 'ignore-non-existent-contents' field to YAML filesBruno Cardoso Lopes1-2/+24
Add 'ignore-non-existent-contents' to tell the VFS whether an invalid path obtained via 'external-contents' should cause iteration on the VFS to stop. If 'true', the VFS should ignore the entry and continue with the next. Allows YAML files to be shared across multiple compiler invocations regardless of prior existent paths in 'external-contents'. This global value is overridable on a per-file basis. This adds the parsing and write test part, but use by VFS comes next. Differential Revision: https://reviews.llvm.org/D23422 rdar://problem/27531549 llvm-svn: 278456
2016-06-13Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh1-4/+12
non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843 Corresponding LLVM change: http://reviews.llvm.org/D19842 Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure. llvm-svn: 272584
2016-06-13Revert r272562 for build bot failure (clang-x86-win2008-selfhost)Taewook Oh1-12/+4
llvm-svn: 272572
2016-06-13Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh1-4/+12
non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843 Corresponding LLVM change: http://reviews.llvm.org/D19842 Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures. Patch by Eric Niebler llvm-svn: 272562
2016-06-12Add some std::move where the value is only read otherwise.Benjamin Kramer1-3/+4
This mostly affects smart pointers. No functionality change intended. llvm-svn: 272520
2016-06-04Revert commit r271708Taewook Oh1-12/+4
llvm-svn: 271761
2016-06-03Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh1-4/+12
non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843 Corresponding LLVM change: http://reviews.llvm.org/D19842 Patch by Eric Niebler llvm-svn: 271708
2016-05-27Apply clang-tidy's misc-move-constructor-init throughout Clang.Benjamin Kramer1-3/+4
No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270996
2016-05-12[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes1-1/+80
Reapply r269100 and r269270, reverted due to https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that corresponds to the new feature side of this commit and skip it on windows hosts until we find why it does not work on these platforms. Original commit message: The way we currently build the internal VFS overlay representation leads to inefficient path search and might yield wrong answers when asked for recursive or regular directory iteration. Currently, when reading an YAML file, each YAML root entry is placed inside a new root in the filesystem overlay. In the crash reproducer, a simple "@import Foundation" currently maps to 43 roots, and when looking up paths, we traverse a directory tree for each of these different roots, until we find a match (or don't). This has two consequences: - It's slow. - Directory iteration gives incomplete results since it only return results within one root - since contents of the same directory can be declared inside different roots, the result isn't accurate. This is in part fault of the way we currently write out the YAML file when emitting the crash reproducer - we could generate only one root and that would make it fast and correct again. However, we should not rely on how the client writes the YAML, but provide a good internal representation regardless. Build a proper virtual directory tree out of the YAML representation, allowing faster search and proper iteration. Besides the crash reproducer, this potentially benefits other VFS clients. llvm-svn: 269327
generated by cgit v1.1 at 2025-10-07 08:48:01 +0000