summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/VirtualFileSystem.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [NFC][VFS] Fix typos in comments.Volodymyr Sapsai2018-08-081-2/+2
| | | | llvm-svn: 339215
* [VFS] Unify iteration code for VFSFromYamlDirIterImpl, NFC intended.Volodymyr Sapsai2018-08-071-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
* [VFS] Emit an error when entry at root level uses a relative path.Volodymyr Sapsai2018-08-071-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
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-08-061-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
* Revert r338057 "[VirtualFileSystem] InMemoryFileSystem::status: Return a ↵Reid Kleckner2018-07-261-51/+14
| | | | | | | | Status with the requested name" This broke clang/test/PCH/case-insensitive-include.c on Windows. llvm-svn: 338084
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-07-261-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
* Revert "[VFS] Cleanups to VFS interfaces."Jordan Rupprecht2018-07-241-19/+18
| | | | | | This reverts commit r337834 due to test failures. llvm-svn: 337850
* [VFS] Cleanups to VFS interfaces.Sam McCall2018-07-241-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
* Revert "[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with ↵Eric Liu2018-07-111-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
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-07-111-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
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-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
* [VFS] Implement getRealPath in InMemoryFileSystem.Eric Liu2018-05-241-0/+13
| | | | | | | | | | Reviewers: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47262 llvm-svn: 333172
* [VFS] Implement getRealPath for OverlayFileSystem.Eric Liu2018-05-181-0/+9
| | | | | | | | | | Reviewers: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47060 llvm-svn: 332717
* Add vfs::FileSystem::getRealPathEric Liu2018-05-171-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
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-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
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-271-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
* Fixes errors with FS iterators caused by https://reviews.llvm.org/D44960Max Moroz2018-04-041-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
* [Basic] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2018-03-281-97/+180
| | | | | | other minor fixes (NFC). llvm-svn: 328735
* [clang] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-03-271-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
* [VirtualFileSystem] Support creating directories then adding files insideBen Hamilton2017-11-161-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
* [VirtualFileSystem] InMemoryFileSystem::addFile(): Type and PermsBen Hamilton2017-11-091-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
* Support: Have directory_iterator::status() return ↵Peter Collingbourne2017-10-101-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
* [vfs] Assert that the status is known in equivalent().Benjamin Kramer2017-07-201-0/+1
| | | | | | Otherwise we'd silently compare uninitialized data. llvm-svn: 308604
* Reapply [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka2017-03-141-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
* Revert "Reapply [VFS] Ignore broken symlinks in the directory iterator."Juergen Ributzka2017-03-111-2/+5
| | | | | | Still broken on Windows and SystemZ bot ... sorry for the noise. llvm-svn: 297533
* Reapply [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka2017-03-101-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
* Revert r297510 "[VFS] Ignore broken symlinks in the directory iterator."Juergen Ributzka2017-03-101-2/+5
| | | | | | The tests are failing on one of the bots. llvm-svn: 297517
* [VFS] Remove the Path variable from RealFSDirIter. NFC.Juergen Ributzka2017-03-101-3/+1
| | | | | | This variable is set, but never used. llvm-svn: 297511
* [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka2017-03-101-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
* Replace use of chdir with llvm::sys::fs::set_current_pathPavel Labath2017-01-241-12/+1
| | | | | | NFCI llvm-svn: 292914
* [CrashReproducer] Add support for merging -ivfsoverlayBruno Cardoso Lopes2016-12-221-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
* [VFS] Replace TimeValue usage with std::chronoPavel Labath2016-11-091-13/+14
| | | | | | | | | | | | Summary: NFCI Reviewers: benlangmuir, zturner Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25948 llvm-svn: 286356
* Reapply [VFS] Skip non existent files from the VFS treeBruno Cardoso Lopes2016-08-121-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
* Revert "[VFS] Skip non existent files from the VFS tree"Bruno Cardoso Lopes2016-08-121-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
* [VFS] Skip non existent files from the VFS treeBruno Cardoso Lopes2016-08-121-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
* [VFS] Add 'ignore-non-existent-contents' field to YAML filesBruno Cardoso Lopes2016-08-121-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
* Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh2016-06-131-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
* Revert r272562 for build bot failure (clang-x86-win2008-selfhost)Taewook Oh2016-06-131-12/+4
| | | | llvm-svn: 272572
* Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh2016-06-131-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
* Add some std::move where the value is only read otherwise.Benjamin Kramer2016-06-121-3/+4
| | | | | | This mostly affects smart pointers. No functionality change intended. llvm-svn: 272520
* Revert commit r271708Taewook Oh2016-06-041-12/+4
| | | | llvm-svn: 271761
* Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh2016-06-031-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
* Apply clang-tidy's misc-move-constructor-init throughout Clang.Benjamin Kramer2016-05-271-3/+4
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270996
* [VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes2016-05-121-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
* Revert "[VFS] Reapply r269100: Reconstruct the VFS overlay tree for more ↵Bruno Cardoso Lopes2016-05-121-80/+1
| | | | | | | | | | accurate lookup" Reverts r269270, buildbots still failing: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/12119 http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/2847 llvm-svn: 269276
* [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes2016-05-121-1/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. This patch builds 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: 269270
* Hopefully bring llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast back to lifeSean Silva2016-05-111-80/+1
| | | | | | | | | Bruno made a couple valiant attempts but the bot is still red. This reverts r269100 (primary commit), r269108 (fix attempt), r269133 (fix attempt). llvm-svn: 269160
* [VFS] Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes2016-05-101-1/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. This patch builds 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: 269100
* [VFS] Add dump methods to the VFS overlay treeBruno Cardoso Lopes2016-05-061-0/+24
| | | | | | Useful when debugging issues within the VFS overlay. llvm-svn: 268820
* [CrashReproducer] Setup 'use-external-names' in YAML files.Bruno Cardoso Lopes2016-04-131-4/+9
| | | | | | | | | | | | | | Hide the real paths when rebuilding from VFS by setting up the crash reproducer to use 'use-external-names' = false. This way we avoid module redifinition errors and consistently use the same paths against all modules. With this change on Darwin we are able to simulate a crash for a simple application using "Foundation/Foundation.h" (which relies on a bunch of different frameworks and headers) and successfully rebuild all the modules by relying solely at the VFS overlay. llvm-svn: 266234
OpenPOWER on IntegriCloud