maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/unittests/Driver/ToolChainTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

263 lines
9.9 KiB
C++
Raw Normal View History

[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
//===- unittests/Driver/ToolChainTest.cpp --- ToolChain tests -------------===//
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
//
//===----------------------------------------------------------------------===//
//
// Unit tests for ToolChains.
//
//===----------------------------------------------------------------------===//
#include "clang/Driver/ToolChain.h"
#include "clang/Basic/DiagnosticIDs.h"
#include "clang/Basic/DiagnosticOptions.h"
#include "clang/Basic/LLVM.h"
#include "clang/Driver/Compilation.h"
#include "clang/Driver/Driver.h"
Use class to pass information about executable name 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
2017-08-29 13:22:26 +08:00
#include "llvm/Support/TargetRegistry.h"
#include "llvm/Support/TargetSelect.h"
Lift VFS from clang to llvm (NFC) 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-10-10 21:27:25 +08:00
#include "llvm/Support/VirtualFileSystem.h"
[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
#include "llvm/Support/raw_ostream.h"
#include "gtest/gtest.h"
using namespace clang;
using namespace clang::driver;
namespace {
TEST(ToolChainTest, VFSGCCInstallation) {
IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
struct TestDiagnosticConsumer : public DiagnosticConsumer {};
DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
Lift VFS from clang to llvm (NFC) 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-10-10 21:27:25 +08:00
IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> InMemoryFileSystem(
new llvm::vfs::InMemoryFileSystem);
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
Driver TheDriver("/bin/clang", "arm-linux-gnueabihf", Diags,
[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
InMemoryFileSystem);
const char *EmptyFiles[] = {
"foo.cpp",
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
"/bin/clang",
[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
"/usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o",
"/usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtend.o",
"/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/crtbegin.o",
"/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/crtend.o",
"/usr/lib/arm-linux-gnueabi/crt1.o",
"/usr/lib/arm-linux-gnueabi/crti.o",
"/usr/lib/arm-linux-gnueabi/crtn.o",
"/usr/lib/arm-linux-gnueabihf/crt1.o",
"/usr/lib/arm-linux-gnueabihf/crti.o",
"/usr/lib/arm-linux-gnueabihf/crtn.o",
"/usr/include/arm-linux-gnueabi/.keep",
"/usr/include/arm-linux-gnueabihf/.keep",
"/lib/arm-linux-gnueabi/.keep",
"/lib/arm-linux-gnueabihf/.keep"};
for (const char *Path : EmptyFiles)
InMemoryFileSystem->addFile(Path, 0,
llvm::MemoryBuffer::getMemBuffer("\n"));
Minor fix in ToolChainTest.cpp to allow user defined GCC toolchain. 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
2015-10-28 06:20:26 +08:00
std::unique_ptr<Compilation> C(TheDriver.BuildCompilation(
Driver tests: set `--sysroot=""` to support clang with `DEFAULT_SYSROOT` 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
2019-09-28 20:21:06 +08:00
{"-fsyntax-only", "--gcc-toolchain=", "--sysroot=", "foo.cpp"}));
Driver must return non-zero code on errors in command line 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
2017-05-24 22:57:17 +08:00
EXPECT_TRUE(C);
[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
std::string S;
{
llvm::raw_string_ostream OS(S);
C->getDefaultToolChain().printVerboseInfo(OS);
}
s/LLVM_ON_WIN32/_WIN32/, clang 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-28 03:11:14 +08:00
#if _WIN32
Fix VFS GCC unittest on Windows llvm-svn: 249846
2015-10-10 00:48:52 +08:00
std::replace(S.begin(), S.end(), '\\', '/');
#endif
[VFS] Wire up multilib toolchain code to the VFS. This lets a VFSified driver actually validate the GCC paths. llvm-svn: 249829
2015-10-09 21:03:18 +08:00
EXPECT_EQ(
"Found candidate GCC installation: "
"/usr/lib/gcc/arm-linux-gnueabihf/4.6.3\n"
"Selected GCC installation: /usr/lib/gcc/arm-linux-gnueabihf/4.6.3\n"
"Candidate multilib: .;@m32\n"
"Selected multilib: .;@m32\n",
S);
[VFS] Port driver tool chains to VFS. 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
2015-10-07 23:48:01 +08:00
}
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
TEST(ToolChainTest, VFSGCCInstallationRelativeDir) {
IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
struct TestDiagnosticConsumer : public DiagnosticConsumer {};
DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
Lift VFS from clang to llvm (NFC) 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-10-10 21:27:25 +08:00
IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> InMemoryFileSystem(
new llvm::vfs::InMemoryFileSystem);
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
Driver TheDriver("/home/test/bin/clang", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
const char *EmptyFiles[] = {
"foo.cpp", "/home/test/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o",
"/home/test/include/arm-linux-gnueabi/.keep"};
for (const char *Path : EmptyFiles)
InMemoryFileSystem->addFile(Path, 0,
llvm::MemoryBuffer::getMemBuffer("\n"));
Minor fix in ToolChainTest.cpp to allow user defined GCC toolchain. 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
2015-10-28 06:20:26 +08:00
std::unique_ptr<Compilation> C(TheDriver.BuildCompilation(
{"-fsyntax-only", "--gcc-toolchain=", "foo.cpp"}));
Driver must return non-zero code on errors in command line 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
2017-05-24 22:57:17 +08:00
EXPECT_TRUE(C);
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
std::string S;
{
llvm::raw_string_ostream OS(S);
C->getDefaultToolChain().printVerboseInfo(OS);
}
s/LLVM_ON_WIN32/_WIN32/, clang 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-28 03:11:14 +08:00
#if _WIN32
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
std::replace(S.begin(), S.end(), '\\', '/');
#endif
EXPECT_EQ("Found candidate GCC installation: "
[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the 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-08-07 05:48:20 +08:00
"/home/test/bin/../lib/gcc/arm-linux-gnueabi/4.6.1\n"
[Driver] Use the parent_path of the clang executable as the default InstalledDir 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
2015-10-13 23:19:32 +08:00
"Selected GCC installation: "
"/home/test/bin/../lib/gcc/arm-linux-gnueabi/4.6.1\n"
"Candidate multilib: .;@m32\n"
"Selected multilib: .;@m32\n",
S);
}
[Driver] Set the default driver mode based on the executable. 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
2016-08-13 01:47:52 +08:00
TEST(ToolChainTest, DefaultDriverMode) {
IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
struct TestDiagnosticConsumer : public DiagnosticConsumer {};
DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
Lift VFS from clang to llvm (NFC) 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-10-10 21:27:25 +08:00
IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> InMemoryFileSystem(
new llvm::vfs::InMemoryFileSystem);
[Driver] Set the default driver mode based on the executable. 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
2016-08-13 01:47:52 +08:00
Driver CCDriver("/home/test/bin/clang", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
Driver must return non-zero code on errors in command line 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
2017-05-24 22:57:17 +08:00
CCDriver.setCheckInputsExist(false);
[Driver] Set the default driver mode based on the executable. 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
2016-08-13 01:47:52 +08:00
Driver CXXDriver("/home/test/bin/clang++", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
Driver must return non-zero code on errors in command line 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
2017-05-24 22:57:17 +08:00
CXXDriver.setCheckInputsExist(false);
[Driver] Set the default driver mode based on the executable. 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
2016-08-13 01:47:52 +08:00
Driver CLDriver("/home/test/bin/clang-cl", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
Driver must return non-zero code on errors in command line 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
2017-05-24 22:57:17 +08:00
CLDriver.setCheckInputsExist(false);
std::unique_ptr<Compilation> CC(CCDriver.BuildCompilation(
{ "/home/test/bin/clang", "foo.cpp"}));
std::unique_ptr<Compilation> CXX(CXXDriver.BuildCompilation(
{ "/home/test/bin/clang++", "foo.cpp"}));
std::unique_ptr<Compilation> CL(CLDriver.BuildCompilation(
{ "/home/test/bin/clang-cl", "foo.cpp"}));
EXPECT_TRUE(CC);
EXPECT_TRUE(CXX);
EXPECT_TRUE(CL);
[Driver] Set the default driver mode based on the executable. 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
2016-08-13 01:47:52 +08:00
EXPECT_TRUE(CCDriver.CCCIsCC());
EXPECT_TRUE(CXXDriver.CCCIsCXX());
EXPECT_TRUE(CLDriver.IsCLMode());
}
[Driver] Actually report errors during parsing instead of stopping when 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
2017-06-30 21:21:27 +08:00
TEST(ToolChainTest, InvalidArgument) {
IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
struct TestDiagnosticConsumer : public DiagnosticConsumer {};
IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
Driver TheDriver("/bin/clang", "arm-linux-gnueabihf", Diags);
std::unique_ptr<Compilation> C(TheDriver.BuildCompilation(
{"-fsyntax-only", "-fan-unknown-option", "foo.cpp"}));
EXPECT_TRUE(C);
EXPECT_TRUE(C->containsError());
}
[Driver] Set the default driver mode based on the executable. 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
2016-08-13 01:47:52 +08:00
Use class to pass information about executable name 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
2017-08-29 13:22:26 +08:00
TEST(ToolChainTest, ParsedClangName) {
ParsedClangName Empty;
EXPECT_TRUE(Empty.TargetPrefix.empty());
EXPECT_TRUE(Empty.ModeSuffix.empty());
EXPECT_TRUE(Empty.DriverMode == nullptr);
EXPECT_FALSE(Empty.TargetIsValid);
ParsedClangName DriverOnly("clang", nullptr);
EXPECT_TRUE(DriverOnly.TargetPrefix.empty());
EXPECT_TRUE(DriverOnly.ModeSuffix == "clang");
EXPECT_TRUE(DriverOnly.DriverMode == nullptr);
EXPECT_FALSE(DriverOnly.TargetIsValid);
ParsedClangName DriverOnly2("clang++", "--driver-mode=g++");
EXPECT_TRUE(DriverOnly2.TargetPrefix.empty());
EXPECT_TRUE(DriverOnly2.ModeSuffix == "clang++");
EXPECT_STREQ(DriverOnly2.DriverMode, "--driver-mode=g++");
EXPECT_FALSE(DriverOnly2.TargetIsValid);
ParsedClangName TargetAndMode("i386", "clang-g++", "--driver-mode=g++", true);
EXPECT_TRUE(TargetAndMode.TargetPrefix == "i386");
EXPECT_TRUE(TargetAndMode.ModeSuffix == "clang-g++");
EXPECT_STREQ(TargetAndMode.DriverMode, "--driver-mode=g++");
EXPECT_TRUE(TargetAndMode.TargetIsValid);
}
TEST(ToolChainTest, GetTargetAndMode) {
llvm::InitializeAllTargets();
std::string IgnoredError;
if (!llvm::TargetRegistry::lookupTarget("x86_64", IgnoredError))
return;
ParsedClangName Res = ToolChain::getTargetAndModeFromProgramName("clang");
EXPECT_TRUE(Res.TargetPrefix.empty());
EXPECT_TRUE(Res.ModeSuffix == "clang");
EXPECT_TRUE(Res.DriverMode == nullptr);
EXPECT_FALSE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("clang++");
EXPECT_TRUE(Res.TargetPrefix.empty());
EXPECT_TRUE(Res.ModeSuffix == "clang++");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=g++");
EXPECT_FALSE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("clang++6.0");
EXPECT_TRUE(Res.TargetPrefix.empty());
EXPECT_TRUE(Res.ModeSuffix == "clang++");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=g++");
EXPECT_FALSE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("clang++-release");
EXPECT_TRUE(Res.TargetPrefix.empty());
EXPECT_TRUE(Res.ModeSuffix == "clang++");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=g++");
EXPECT_FALSE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("x86_64-clang++");
EXPECT_TRUE(Res.TargetPrefix == "x86_64");
EXPECT_TRUE(Res.ModeSuffix == "clang++");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=g++");
EXPECT_TRUE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName(
"x86_64-linux-gnu-clang-c++");
EXPECT_TRUE(Res.TargetPrefix == "x86_64-linux-gnu");
EXPECT_TRUE(Res.ModeSuffix == "clang-c++");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=g++");
EXPECT_TRUE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName(
"x86_64-linux-gnu-clang-c++-tot");
EXPECT_TRUE(Res.TargetPrefix == "x86_64-linux-gnu");
EXPECT_TRUE(Res.ModeSuffix == "clang-c++");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=g++");
EXPECT_TRUE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("qqq");
EXPECT_TRUE(Res.TargetPrefix.empty());
EXPECT_TRUE(Res.ModeSuffix.empty());
EXPECT_TRUE(Res.DriverMode == nullptr);
EXPECT_FALSE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("x86_64-qqq");
EXPECT_TRUE(Res.TargetPrefix.empty());
EXPECT_TRUE(Res.ModeSuffix.empty());
EXPECT_TRUE(Res.DriverMode == nullptr);
EXPECT_FALSE(Res.TargetIsValid);
Res = ToolChain::getTargetAndModeFromProgramName("qqq-clang-cl");
EXPECT_TRUE(Res.TargetPrefix == "qqq");
EXPECT_TRUE(Res.ModeSuffix == "clang-cl");
EXPECT_STREQ(Res.DriverMode, "--driver-mode=cl");
EXPECT_FALSE(Res.TargetIsValid);
}
Testing commit access. 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
2017-04-19 01:34:46 +08:00
} // end anonymous namespace.