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

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

62 lines
3.4 KiB
C++
Raw Normal View History

[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// Backslash escaping makes matching against the installation directory fail on
// Windows. Temporarily disable the test there until we add an option to print
// the installation directory unescaped.
// UNSUPPORTED: system-windows
// By default, we should search for libc++ next to the driver.
// RUN: mkdir -p %t/bin
// RUN: mkdir -p %t/include/c++/v1
Reland 198fbcb8, "Driver: Don't look for libc++ headers in the install directory on Android.", which was reverted in b3249027. Fixed the test case to set --sysroot, which lets it succeed in the case where a directory named "/usr/include/c++/v1" or "/usr/local/include/c++/v1" exists. Original commit message: > The NDK uses a separate set of libc++ headers in the sysroot. Any headers > in the installation directory are not going to work on Android, not least > because they use a different name for the inline namespace (std::__1 instead > of std::__ndk1). > > This effectively makes it impossible to produce a single toolchain that is > capable of targeting both Android and another platform that expects libc++ > headers to be installed in the installation directory, such as Mac. > > In order to allow this scenario to work, stop looking for headers in the > install directory on Android. Differential Revision: https://reviews.llvm.org/D71154
2019-12-07 07:54:47 +08:00
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// RUN: -stdlib=libc++ -fsyntax-only %s -### 2>&1 | \
// RUN: FileCheck -check-prefix=LIBCXX %s
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %t/bin \
// RUN: -stdlib=libc++ -fsyntax-only %s -### 2>&1 | \
// RUN: FileCheck -check-prefix=LIBCXX %s
// LIBCXX: InstalledDir: [[INSTALLDIR:.+$]]
// LIBCXX: "-internal-isystem" "[[INSTALLDIR]]/../include/c++/v1"
// Passing -stdlib++-isystem should suppress the default search.
Reland 198fbcb8, "Driver: Don't look for libc++ headers in the install directory on Android.", which was reverted in b3249027. Fixed the test case to set --sysroot, which lets it succeed in the case where a directory named "/usr/include/c++/v1" or "/usr/local/include/c++/v1" exists. Original commit message: > The NDK uses a separate set of libc++ headers in the sysroot. Any headers > in the installation directory are not going to work on Android, not least > because they use a different name for the inline namespace (std::__1 instead > of std::__ndk1). > > This effectively makes it impossible to produce a single toolchain that is > capable of targeting both Android and another platform that expects libc++ > headers to be installed in the installation directory, such as Mac. > > In order to allow this scenario to work, stop looking for headers in the > install directory on Android. Differential Revision: https://reviews.llvm.org/D71154
2019-12-07 07:54:47 +08:00
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -stdlib=libc++ \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck -check-prefix=NODEFAULT %s
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %t/bin \
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -stdlib=libc++ \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck -check-prefix=NODEFAULT %s
// NODEFAULT: InstalledDir: [[INSTALLDIR:.+$]]
// NODEFAULT-NOT: "-internal-isystem" "[[INSTALLDIR]]/../include/c++/v1"
// And we should add it as an -internal-isystem.
Reland 198fbcb8, "Driver: Don't look for libc++ headers in the install directory on Android.", which was reverted in b3249027. Fixed the test case to set --sysroot, which lets it succeed in the case where a directory named "/usr/include/c++/v1" or "/usr/local/include/c++/v1" exists. Original commit message: > The NDK uses a separate set of libc++ headers in the sysroot. Any headers > in the installation directory are not going to work on Android, not least > because they use a different name for the inline namespace (std::__1 instead > of std::__ndk1). > > This effectively makes it impossible to produce a single toolchain that is > capable of targeting both Android and another platform that expects libc++ > headers to be installed in the installation directory, such as Mac. > > In order to allow this scenario to work, stop looking for headers in the > install directory on Android. Differential Revision: https://reviews.llvm.org/D71154
2019-12-07 07:54:47 +08:00
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -stdlib=libc++ \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck -check-prefix=INCPATH %s
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %t/bin \
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -stdlib=libc++ \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck -check-prefix=INCPATH %s
// INCPATH: "-internal-isystem" "/tmp/foo" "-internal-isystem" "/tmp/bar"
// We shouldn't pass the -stdlib++-isystem to cc1.
Reland 198fbcb8, "Driver: Don't look for libc++ headers in the install directory on Android.", which was reverted in b3249027. Fixed the test case to set --sysroot, which lets it succeed in the case where a directory named "/usr/include/c++/v1" or "/usr/local/include/c++/v1" exists. Original commit message: > The NDK uses a separate set of libc++ headers in the sysroot. Any headers > in the installation directory are not going to work on Android, not least > because they use a different name for the inline namespace (std::__1 instead > of std::__ndk1). > > This effectively makes it impossible to produce a single toolchain that is > capable of targeting both Android and another platform that expects libc++ > headers to be installed in the installation directory, such as Mac. > > In order to allow this scenario to work, stop looking for headers in the > install directory on Android. Differential Revision: https://reviews.llvm.org/D71154
2019-12-07 07:54:47 +08:00
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// RUN: -stdlib++-isystem /tmp -stdlib=libc++ -fsyntax-only %s -### 2>&1 | \
// RUN: FileCheck -check-prefix=NOCC1 %s
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %t/bin \
// RUN: -stdlib++-isystem /tmp -stdlib=libc++ -fsyntax-only %s -### 2>&1 | \
// RUN: FileCheck -check-prefix=NOCC1 %s
// NOCC1-NOT: "-stdlib++-isystem" "/tmp"
[Driver] Suppress libstdc++/libc++ path with -nostdinc This follows GCC. Having libstdc++/libc++ include paths is not useful anyway because libstdc++/libc++ header files cannot find features.h. While here, suppress -stdlib++-isystem with -nostdlibinc.
2021-03-29 02:30:27 +08:00
// It should respect -nostdinc++
Reland 198fbcb8, "Driver: Don't look for libc++ headers in the install directory on Android.", which was reverted in b3249027. Fixed the test case to set --sysroot, which lets it succeed in the case where a directory named "/usr/include/c++/v1" or "/usr/local/include/c++/v1" exists. Original commit message: > The NDK uses a separate set of libc++ headers in the sysroot. Any headers > in the installation directory are not going to work on Android, not least > because they use a different name for the inline namespace (std::__1 instead > of std::__ndk1). > > This effectively makes it impossible to produce a single toolchain that is > capable of targeting both Android and another platform that expects libc++ > headers to be installed in the installation directory, such as Mac. > > In order to allow this scenario to work, stop looking for headers in the > install directory on Android. Differential Revision: https://reviews.llvm.org/D71154
2019-12-07 07:54:47 +08:00
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -nostdinc++ \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck -check-prefix=NOSTDINCXX %s
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %t/bin \
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -nostdinc++ \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck -check-prefix=NOSTDINCXX %s
[Driver] Suppress libstdc++/libc++ path with -nostdinc This follows GCC. Having libstdc++/libc++ include paths is not useful anyway because libstdc++/libc++ header files cannot find features.h. While here, suppress -stdlib++-isystem with -nostdlibinc.
2021-03-29 02:30:27 +08:00
// ... and -nostdinc and -nostdlibinc.
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -nostdinc \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck --check-prefix=NOSTDINCXX %s
// RUN: %clang -target aarch64-linux-gnu -ccc-install-dir %t/bin \
// RUN: -stdlib++-isystem /tmp/foo -stdlib++-isystem /tmp/bar -nostdlibinc \
// RUN: -fsyntax-only %s -### 2>&1 | FileCheck --check-prefix=NOSTDINCXX %s
[Driver] Introduce -stdlib++-isystem There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
2019-08-06 14:48:43 +08:00
// NOSTDINCXX-NOT: "-internal-isystem" "/tmp/foo" "-internal-isystem" "/tmp/bar"