summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Driver/ToolChainTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Driver tests: set `--sysroot=""` to support clang with `DEFAULT_SYSROOT`Serge Pavlov2019-09-281-1/+1
| | | | | | | | | | | | When testing clang that has been compiled with `-DDEFAULT_SYSROOT` set to some path, some tests would fail. Override sysroot to be empty string for the tests to succeed when clang is configured with `DEFAULT_SYSROOT`. Differential Revision: https://reviews.llvm.org/D66834 Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com>. llvm-svn: 373147
* 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
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-7/+7
| | | | | | | | | | | | | | | | | | | 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
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 "[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with ↵Eric Liu2018-07-111-1/+1
| | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Use class to pass information about executable nameSerge Pavlov2017-08-291-0/+96
| | | | | | | | | | | | | Information about clang executable name components, such as target and driver mode, was passes in std::pair. With this change it is passed in a special structure. It improves readability and makes access to this information more convenient. NFC. Differential Revision: https://reviews.llvm.org/D36057 llvm-svn: 311981
* [Driver] Actually report errors during parsing instead of stopping when ↵Benjamin Kramer2017-06-301-0/+11
| | | | | | | | | | | | | | there's an error somewhere. This is a more principled version of r303756. That change was both very brittle about the state of the Diags object going into the driver and also broke tooling in funny ways. In particular it prevented tools from capturing diagnostics properly and made the compilation database logic fail to provide arguments to the tool, falling back to scanning directories for JSON files. llvm-svn: 306822
* Driver must return non-zero code on errors in command lineSerge Pavlov2017-05-241-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is recommit of r302775, reverted in r302777 due to a fail in clang-tidy. Original mesage is below. Now if clang driver is given wrong arguments, in some cases it continues execution and returns zero code. This change fixes this behavior. The fix revealed some errors in clang test set. File test/Driver/gfortran.f90 added in r118203 checks forwarding gfortran flags to GCC. Now driver reports error on this file, because the option -working-directory implemented in clang differs from the option with the same name implemented in gfortran, in clang the option requires argument, in gfortran does not. In the file test/Driver/arm-darwin-builtin.c clang is called with options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed in r191435 and now clang reports error on this test. File arm-default-build-attributes.s uses option -verify, which is not supported by driver, it is cc1 option. Similarly, the file split-debug.h uses options -fmodules-embed-all-files and -fmodule-format=obj, which are not supported by driver. Other revealed errors are mainly mistypes. Differential Revision: https://reviews.llvm.org/D33013 llvm-svn: 303756
* Testing commit access.Manoj Gupta2017-04-181-1/+1
| | | | | | | | | | | | | | Summary: Test commit access. Reviewers: gbiv, george.burgess.iv Reviewed By: george.burgess.iv Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D32161 llvm-svn: 300570
* [Driver] Set the default driver mode based on the executable.Zachary Turner2016-08-121-0/+25
| | | | | | | | | | | | | | | | | | Currently, if --driver-mode is not passed at all, it will default to GCC style driver. This is never an issue for clang because it manually constructs a --driver-mode option and passes it. However, we should still try to do as good as we can even if no --driver-mode is passed. LibTooling, for example, does not pass a --driver-mode option and while it could, it seems like we should still fallback to the best possible default we can. This is one of two steps necessary to get clang-tidy working on Windows. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D23454 llvm-svn: 278535
* Minor fix in ToolChainTest.cpp to allow user defined GCC toolchain.Samuel Antao2015-10-271-4/+4
| | | | | | | If the user configured clang with a custom GCC toolchain that will take precedence on what the ToolChainTest.cpp expects to evaluate. This is fixed here by passing --gcc-toolchain= to the driver, in order to override any user defined GCC toolchain. llvm-svn: 251459
* [Driver] Use the parent_path of the clang executable as the default InstalledDirBenjamin Kramer2015-10-131-2/+41
| | | | | | | | This is what most people want anyways. Clang -cc1's main() will override this but for other tools this is the most sensible default and avoids some work. llvm-svn: 250164
* Fix VFS GCC unittest on WindowsReid Kleckner2015-10-091-0/+3
| | | | llvm-svn: 249846
* [VFS] Wire up multilib toolchain code to the VFS.Benjamin Kramer2015-10-091-3/+7
| | | | | | This lets a VFSified driver actually validate the GCC paths. llvm-svn: 249829
* [VFS] Port driver tool chains to VFS.Benjamin Kramer2015-10-071-0/+74
There are still some loose ends here but it's sufficient so we can detect GCC headers that are inside of a VFS. llvm-svn: 249556
OpenPOWER on IntegriCloud