summaryrefslogtreecommitdiffstats
path: root/unittests/Basic
Commit message (Collapse)AuthorAgeFilesLines
* Added braces to work around gcc warning in googletest: suggest explicit ↵Galina Kistanova2017-06-151-2/+4
| | | | | | braces to avoid ambiguous 'else'. NFC. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305507 91177308-0d34-0410-b5e6-96231b3b80d8
* Add #pragma clang module build/endbuild pragmas for performing a module buildRichard Smith2017-06-091-21/+3
| | | | | | | | | | | | | | | | as part of a compilation. This is intended for two purposes: 1) Writing self-contained test cases for modules: we can now write a single source file test that builds some number of module files on the side and imports them. 2) Debugging / test case reduction. A single-source testcase is much more amenable to reduction, compared to a VFS tarball or .pcm files. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305101 91177308-0d34-0410-b5e6-96231b3b80d8
* [modules] Round-trip -Werror flag through explicit module build.Richard Smith2017-05-031-17/+20
| | | | | | | | | | | | | | | | The intent for an explicit module build is that the diagnostics produced within the module are those that were configured when the module was built, not those that are enabled within a user of the module. This includes diagnostics that don't actually show up until the module is used (for instance, diagnostics produced during template instantiation and weird cases like -Wpadded). We serialized and restored the diagnostic state for individual warning groups, but previously did not track the state for flags like -Werror and -Weverything, which are implemented as separate bits rather than as part of the diagnostics mapping information. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301992 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Revert "PPCallbacks::MacroUndefined, change signature and add test.""Vedant Kumar2017-04-261-22/+52
| | | | | | | This reverts commit r301469. It isn't needed with r301470, which fixes the API break introduced in the original commit. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301472 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "PPCallbacks::MacroUndefined, change signature and add test."Vedant Kumar2017-04-261-52/+22
| | | | | | | | This reverts commit r301449. It breaks the build with: MacroPPCallbacks.h:114:50: error: non-virtual member function marked 'override' hides virtual member function git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301469 91177308-0d34-0410-b5e6-96231b3b80d8
* PPCallbacks::MacroUndefined, change signature and add test.Frederich Munch2017-04-261-22/+52
| | | | | | | | | | | | | | | | Summary: The PPCallbacks::MacroUndefined callback is currently insufficient for clients that need to track the MacroDirectives. This patch adds an additional argument to PPCallbacks::MacroUndefined that is the undef MacroDirective. Reviewers: bruno, manmanren Reviewed By: bruno Subscribers: nemanjai, cfe-commits Differential Revision: https://reviews.llvm.org/D29923 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301449 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298905 91177308-0d34-0410-b5e6-96231b3b80d8
* Modules: Remove an invalid check in unit tests for r298278Duncan P. N. Exon Smith2017-03-211-1/+0
| | | | | | | | | | | | | This is a fixup for the unit tests from r298278 (originally r298165). Since the buffer that RawB2 pointed at was later deleted, a new call to getBuffer may very well return a buffer at the same/old address. Which is fine. Just delete the spurious check. A Windows bot was occasionally hitting this in practice: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/7086 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298414 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"Duncan P. N. Exon Smith2017-03-203-3/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r298185, effectively reapplying r298165, after fixing the new unit tests (PR32338). The memory buffer generator doesn't null-terminate the MemoryBuffer it creates; this version of the commit informs getMemBuffer about that to avoid the assert. Original commit message follows: ---- Clang's internal build system for implicit modules uses lock files to ensure that after a process writes a PCM it will read the same one back in (without contention from other -cc1 commands). Since PCMs are read from disk repeatedly while invalidating, building, and importing, the lock is not released quickly. Furthermore, the LockFileManager is not robust in every environment. Other -cc1 commands can stall until timeout (after about eight minutes). This commit changes the lock file from being necessary for correctness to a (possibly dubious) performance hack. The remaining benefit is to reduce duplicate work in competing -cc1 commands which depend on the same module. Follow-up commits will change the internal build system to continue after a timeout, and reduce the timeout. Perhaps we should reconsider blocking at all. This also fixes a use-after-free, when one part of a compilation validates a PCM and starts using it, and another tries to swap out the PCM for something new. The PCMCache is a new type called MemoryBufferCache, which saves memory buffers based on their filename. Its ownership is shared by the CompilerInstance and ModuleManager. - The ModuleManager stores PCMs there that it loads from disk, never touching the disk if the cache is hot. - When modules fail to validate, they're removed from the cache. - When a CompilerInstance is spawned to build a new module, each already-loaded PCM is assumed to be valid, and is frozen to avoid the use-after-free. - Any newly-built module is written directly to the cache to avoid the round-trip to the filesystem, making lock files unnecessary for correctness. Original patch by Manman Ren; most testcases by Adrian Prantl! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298278 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Modules: Cache PCMs in memory and avoid a use-after-free"Renato Golin2017-03-183-102/+3
| | | | | | This reverts commit r298165, as it broke the ARM builds. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298185 91177308-0d34-0410-b5e6-96231b3b80d8
* Modules: Cache PCMs in memory and avoid a use-after-freeDuncan P. N. Exon Smith2017-03-173-3/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang's internal build system for implicit modules uses lock files to ensure that after a process writes a PCM it will read the same one back in (without contention from other -cc1 commands). Since PCMs are read from disk repeatedly while invalidating, building, and importing, the lock is not released quickly. Furthermore, the LockFileManager is not robust in every environment. Other -cc1 commands can stall until timeout (after about eight minutes). This commit changes the lock file from being necessary for correctness to a (possibly dubious) performance hack. The remaining benefit is to reduce duplicate work in competing -cc1 commands which depend on the same module. Follow-up commits will change the internal build system to continue after a timeout, and reduce the timeout. Perhaps we should reconsider blocking at all. This also fixes a use-after-free, when one part of a compilation validates a PCM and starts using it, and another tries to swap out the PCM for something new. The PCMCache is a new type called MemoryBufferCache, which saves memory buffers based on their filename. Its ownership is shared by the CompilerInstance and ModuleManager. - The ModuleManager stores PCMs there that it loads from disk, never touching the disk if the cache is hot. - When modules fail to validate, they're removed from the cache. - When a CompilerInstance is spawned to build a new module, each already-loaded PCM is assumed to be valid, and is frozen to avoid the use-after-free. - Any newly-built module is written directly to the cache to avoid the round-trip to the filesystem, making lock files unnecessary for correctness. Original patch by Manman Ren; most testcases by Adrian Prantl! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298165 91177308-0d34-0410-b5e6-96231b3b80d8
* Add more debugging code for the SystemZ bot.Juergen Ributzka2017-03-141-12/+24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297759 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka2017-03-141-0/+90
| | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297693 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Reapply [VFS] Ignore broken symlinks in the directory iterator."Juergen Ributzka2017-03-111-75/+0
| | | | | | Still broken on Windows and SystemZ bot ... sorry for the noise. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297533 91177308-0d34-0410-b5e6-96231b3b80d8
* Adding debug output to investigate systemz bot issue.Juergen Ributzka2017-03-111-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297531 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka2017-03-101-0/+74
| | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297528 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r297510 "[VFS] Ignore broken symlinks in the directory iterator."Juergen Ributzka2017-03-101-83/+0
| | | | | | The tests are failing on one of the bots. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297517 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Ignore broken symlinks in the directory iterator.Juergen Ributzka2017-03-101-0/+83
| | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297510 91177308-0d34-0410-b5e6-96231b3b80d8
* shared_ptrify (from InclusiveRefCntPtr) HeaderSearchOptionsDavid Blaikie2017-01-061-6/+6
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291202 91177308-0d34-0410-b5e6-96231b3b80d8
* Move PreprocessorOptions to std::shared_ptr from IntrusiveRefCntPtrDavid Blaikie2017-01-051-6/+6
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291160 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Replace TimeValue usage with std::chronoPavel Labath2016-11-091-6/+9
| | | | | | | | | | | | Summary: NFCI Reviewers: benlangmuir, zturner Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25948 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286356 91177308-0d34-0410-b5e6-96231b3b80d8
* Turn FileManager DirectoryEntry::Name from raw pointer to StringRef (NFC)Mehdi Amini2016-10-111-8/+8
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283856 91177308-0d34-0410-b5e6-96231b3b80d8
* Store FileEntry::Filename as a StringRef instead of raw pointer (NFC)Mehdi Amini2016-10-101-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283815 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275882 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Add level() method to vfs::recursive_directory_iteratorBruno Cardoso Lopes2016-05-141-0/+42
| | | | | | | | | | | | | Unlike sys::fs::recursive_directory_iterator, vfs::recursive_directory_iterator does not implement the level() method, which tells how deep in the directory tree the current iterator is. This is needed in the vfs::recursive_directory_iterator so that future improvements to the crash reproducer will be able to properly access header for umbrellas when looking into the VFS. rdar://problem/25880368 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269520 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes2016-05-121-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269327 91177308-0d34-0410-b5e6-96231b3b80d8
* [Unittests] Reverse the order of arguments for correct debug outputBruno Cardoso Lopes2016-05-121-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269326 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[VFS] Reapply r269100: Reconstruct the VFS overlay tree for more ↵Bruno Cardoso Lopes2016-05-121-29/+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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269276 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes2016-05-121-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269270 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS][Unittests] Make dir iteration tests depend only on contentBruno Cardoso Lopes2016-05-111-9/+16
| | | | | | | Do not rely on any specific order while comparing the results of directory iteration. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269234 91177308-0d34-0410-b5e6-96231b3b80d8
* Hopefully bring llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast back to lifeSean Silva2016-05-111-30/+1
| | | | | | | | | Bruno made a couple valiant attempts but the bot is still red. This reverts r269100 (primary commit), r269108 (fix attempt), r269133 (fix attempt). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269160 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] One more unittest change to fix win10 buildbotBruno Cardoso Lopes2016-05-101-1/+1
| | | | | | | http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/5110 Follow up from r269100. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269133 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Change unittest to try appeasing win10 buildbotBruno Cardoso Lopes2016-05-101-2/+2
| | | | | | | http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/5103 Follow up from r269100. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269108 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Reconstruct the VFS overlay tree for more accurate lookupBruno Cardoso Lopes2016-05-101-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269100 91177308-0d34-0410-b5e6-96231b3b80d8
* Basic: move CodeGenOptions from FrontendSaleem Abdulrasool2016-04-071-1/+0
| | | | | | | | This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265702 91177308-0d34-0410-b5e6-96231b3b80d8
* Basic: thread CodeGenOptions into TargetInfoSaleem Abdulrasool2016-04-071-0/+1
| | | | | | | | | This threads CodeGenOptions into the TargetInfo hierarchy. This is motivated by ARM which can change some target information based on the EABI selected (-meabi). Similar options exist for other platforms (e.g. MIPS) and thus is generally useful. NFC. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265640 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply [2] [VFS] Add 'overlay-relative' field to YAML filesBruno Cardoso Lopes2016-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263893 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Reapply [VFS] Add 'overlay-relative' field to YAML files"Bruno Cardoso Lopes2016-03-171-1/+1
| | | | | | | | | Tests failing on http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/46102 This reverts commit a1683cd6c9e07359c09f86e98a4db6b4e1bc51fc. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263750 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply [VFS] Add 'overlay-relative' field to YAML filesBruno Cardoso Lopes2016-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r261552. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263748 91177308-0d34-0410-b5e6-96231b3b80d8
* Make TargetInfo store an actual DataLayout instead of a string.James Y Knight2016-03-041-7/+12
| | | | | | | | | | | | | | Use it to calculate UserLabelPrefix, instead of specifying it (often incorrectly). Note that the *actual* user label prefix has always come from the DataLayout, and is handled within LLVM. The main thing clang's TargetInfo::UserLabelPrefix did was to set the #define value. Having these be different from each-other is just silly. Differential Revision: http://reviews.llvm.org/D17183 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262737 91177308-0d34-0410-b5e6-96231b3b80d8
* Optionally demote fatal errors to non-fatal errors.Manuel Klimek2016-03-011-0/+23
| | | | | | | | | | | | | | | | | | This behavior is enabled when the new CXTranslationUnit_KeepGoing option is passed to clang_parseTranslationUnit{,2}. It is geared towards use by IDEs and similar consumers of the clang-c API where fatal errors may arise when parsing incomplete code mid-edit, or when include paths are not properly configured yet. In such situations one still wants to get as much information as possible about a TU. Previously, the semantic analysis would not instantiate templates or report additional fatal errors after the first fatal error was encountered. Fixes PR24268. Patch by Milian Wolff. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262318 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix ↵Bruno Cardoso Lopes2016-02-231-1/+1
| | | | | | | | | | | | | | | call to getVFSFromYAML in unittests" This reverts commit r261552 and r261556 because of failing unittests on windows: Failing Tests (4): Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261613 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Fix call to getVFSFromYAML in unittestsBruno Cardoso Lopes2016-02-221-1/+1
| | | | | | Follow up from r261552 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261556 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove autoconf supportChris Bieneman2016-01-261-15/+0
| | | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "This is the way [autoconf] ends Not with a bang but a whimper." -T.S. Eliot Reviewers: chandlerc, grosbach, bob.wilson, echristo Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D16472 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258862 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes.Eugene Zelenko2016-01-261-2/+1
| | | | | | | Differential revision: http://reviews.llvm.org/D16567 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258836 91177308-0d34-0410-b5e6-96231b3b80d8
* Simplify test code with initializer lists.Benjamin Kramer2016-01-101-47/+16
| | | | | | No functional change intended. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257287 91177308-0d34-0410-b5e6-96231b3b80d8
* Make test work on windows by turning \ in paths back into /.Benjamin Kramer2016-01-101-2/+8
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257286 91177308-0d34-0410-b5e6-96231b3b80d8
* [vfs] Normalize working directory if requested.Benjamin Kramer2016-01-091-0/+6
| | | | | | | | FixedCompilationDatabase sets the working dir to "." by default. For chdir(".") this is a noop but this lead to InMemoryFileSystem to create bogus paths. Fixes PR25327. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257260 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Fix status() of opened redirected fileBen Langmuir2015-12-101-1/+26
| | | | | | | | | | | | | | | Make RedirectedFileSystem::openFilForRead(path)->status() the same as RedirectedFileSystem::status(path). Previously we would just get the status of the underlying real file, which would not have the IsVFSMapped bit set. This fixes rebuilding a module that has an include that is relative to the includer where we will lookup the real path of that file before we lookup the VFS location. rdar://problem/23640339 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255312 91177308-0d34-0410-b5e6-96231b3b80d8
* [VFS] Let the user decide if they want path normalization.Benjamin Kramer2015-10-121-2/+31
| | | | | | | | | | | | | | This is a more principled version of what I did earlier. Path normalization is generally a good thing, but may break users in strange environments, e. g. using lots of symlinks. Let the user choose and default it to on. This also changes adding a duplicated file into returning an error if the file contents are different instead of an assertion failure. Differential Revision: http://reviews.llvm.org/D13658 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250060 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 23:17:50 +0000