llvm-project/clang/test/Driver/darwin-stdlib.cpp

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

15 lines
1.4 KiB
C++
Raw Normal View History

// This test will fail if CLANG_DEFAULT_CXX_STDLIB is set to anything different
// than the platform default. (see https://llvm.org/bugs/show_bug.cgi?id=30548)
// XFAIL: default-cxx-stdlib-set
Move detection of libc++ include dirs to Driver on MacOS Summary: The intention is to make the tools replaying compilations from 'compile_commands.json' (clang-tidy, clangd, etc.) find the same standard library as the original compiler specified in 'compile_commands.json'. Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied on the value of resource dir as an approximation of the compiler install dir. The new logic uses the actual compiler install dir and is performed in the driver. This is consistent with the C++ standard library detection on other platforms and allows to override the resource dir in the tools using the compile_commands.json without altering the standard library detection mechanism. The tools have to override the resource dir to make sure they use a consistent version of the builtin headers. There is still logic in InitHeaderSearch that attemps to add the absolute includes for the the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too, but it could potentially break the library detection on other systems, so we don't tackle it in this patch to keep its scope manageable. This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675. The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke the libc++ detection in clang itself, which caused LLDB tests to break. The LLDB tests pass with new fix. Reviewers: JDevlieghere, arphaman, EricWF Reviewed By: arphaman Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54630 llvm-svn: 348365
2018-12-05 22:24:14 +08:00
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %S/Inputs/darwin_toolchain_tree/bin/ -arch arm64 -miphoneos-version-min=7.0 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LIBCXX
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %S/Inputs/darwin_toolchain_tree/bin/ -mmacosx-version-min=10.8 -Wno-stdlibcxx-not-found %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LIBSTDCXX
Move detection of libc++ include dirs to Driver on MacOS Summary: The intention is to make the tools replaying compilations from 'compile_commands.json' (clang-tidy, clangd, etc.) find the same standard library as the original compiler specified in 'compile_commands.json'. Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied on the value of resource dir as an approximation of the compiler install dir. The new logic uses the actual compiler install dir and is performed in the driver. This is consistent with the C++ standard library detection on other platforms and allows to override the resource dir in the tools using the compile_commands.json without altering the standard library detection mechanism. The tools have to override the resource dir to make sure they use a consistent version of the builtin headers. There is still logic in InitHeaderSearch that attemps to add the absolute includes for the the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too, but it could potentially break the library detection on other systems, so we don't tackle it in this patch to keep its scope manageable. This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675. The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke the libc++ detection in clang itself, which caused LLDB tests to break. The LLDB tests pass with new fix. Reviewers: JDevlieghere, arphaman, EricWF Reviewed By: arphaman Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54630 llvm-svn: 348365
2018-12-05 22:24:14 +08:00
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %S/Inputs/darwin_toolchain_tree/bin/ -mmacosx-version-min=10.9 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LIBCXX
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %S/Inputs/darwin_toolchain_tree/bin/ -arch armv7s -miphoneos-version-min=6.1 -Wno-stdlibcxx-not-found %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LIBSTDCXX
Move detection of libc++ include dirs to Driver on MacOS Summary: The intention is to make the tools replaying compilations from 'compile_commands.json' (clang-tidy, clangd, etc.) find the same standard library as the original compiler specified in 'compile_commands.json'. Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied on the value of resource dir as an approximation of the compiler install dir. The new logic uses the actual compiler install dir and is performed in the driver. This is consistent with the C++ standard library detection on other platforms and allows to override the resource dir in the tools using the compile_commands.json without altering the standard library detection mechanism. The tools have to override the resource dir to make sure they use a consistent version of the builtin headers. There is still logic in InitHeaderSearch that attemps to add the absolute includes for the the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too, but it could potentially break the library detection on other systems, so we don't tackle it in this patch to keep its scope manageable. This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675. The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke the libc++ detection in clang itself, which caused LLDB tests to break. The LLDB tests pass with new fix. Reviewers: JDevlieghere, arphaman, EricWF Reviewed By: arphaman Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54630 llvm-svn: 348365
2018-12-05 22:24:14 +08:00
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %S/Inputs/darwin_toolchain_tree/bin/ -arch armv7s -miphoneos-version-min=7.0 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LIBCXX
// RUN: %clang -target x86_64-apple-darwin -ccc-install-dir %S/Inputs/darwin_toolchain_tree/bin/ -arch armv7k %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LIBCXX
Move detection of libc++ include dirs to Driver on MacOS Summary: The intention is to make the tools replaying compilations from 'compile_commands.json' (clang-tidy, clangd, etc.) find the same standard library as the original compiler specified in 'compile_commands.json'. Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied on the value of resource dir as an approximation of the compiler install dir. The new logic uses the actual compiler install dir and is performed in the driver. This is consistent with the C++ standard library detection on other platforms and allows to override the resource dir in the tools using the compile_commands.json without altering the standard library detection mechanism. The tools have to override the resource dir to make sure they use a consistent version of the builtin headers. There is still logic in InitHeaderSearch that attemps to add the absolute includes for the the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too, but it could potentially break the library detection on other systems, so we don't tackle it in this patch to keep its scope manageable. This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675. The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke the libc++ detection in clang itself, which caused LLDB tests to break. The LLDB tests pass with new fix. Reviewers: JDevlieghere, arphaman, EricWF Reviewed By: arphaman Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54630 llvm-svn: 348365
2018-12-05 22:24:14 +08:00
// CHECK-LIBCXX: "-stdlib=libc++"
// CHECK-LIBSTDCXX-NOT: -stdlib=libc++
// CHECK-LIBSTDCXX-NOT: -stdlib=libstdc++