The tests for libc++ specify -target on the command-line to the
compiler, but this is problematic for a few reasons.
Firstly, the -target option isn't supported on Apple platforms. Parts
of the triple get dropped and ignored. Instead, software should be
compiled with a combination of the -arch and -m<name>-version-min
options.
Secondly, the generic "darwin" target references a kernel version
instead of a platform version. Each platform has its own independent
versions (with different versions of libc++.1.dylib), independent of the
version of the Darwin kernel.
This commit adds support to the LIT infrastructure for testing against
Apple platforms using -arch and -platform options.
If the host is not on OS X, or the compiler type is not clang or apple-clang, then this commit has NFC.
If the host is on OS X and --param=target_triple=... is specified, then a warning is emitted to use arch and platform instead. Besides the warning, there's NFC.
If the host is on OS X and *no* target-triple is specified, then use the new deployment target logic. This uses two new lit parameters, --param=arch=<arch> and --param=platform=<platform>. <platform> has the form <name>[<version>].
By default, arch is auto-detected from clang -dumpmachine, and platform is "macosx".
If the platform doesn't have a version:
For "macosx", the version is auto-detected from the host system using sw_vers. This may give a different version than the SDK, since new SDKs can be installed on older hosts.
Otherwise, the version is auto-detected from the SDK version using xcrun --show-sdk-path.
-arch <arch> -m<name>-version-min=<version> is added to the compiler flags.
The target triple is computed as <arch>-apple-<platform>. It is *not* passed to clang, but it is available for XFAIL and UNSUPPORTED (as is with_system_cxx_lib=<target>).
For convenience, apple-darwin and <arch>-apple-darwin are added to the set of available features.
There were a number of tests marked to XFAIL on x86_64-apple-darwin11
and x86_64-apple-darwin12. I updated these to
x86_64-apple-macosx10.7 and x86_64-apple-macosx10.8.
llvm-svn: 297798
r296565 attempted to add better diagnostics when an unordered container
is instantiated with a hash that doesn't meet the Hash requirements.
However I mistakenly checked the wrong set of requirements. Specifically
it checked if the hash met the requirements for specializations of
std::hash. However these requirements are stricter than the generic
Hash requirements.
This patch fixes the assertions to only check the Hash requirements.
llvm-svn: 296919
The test is passing with c++11 and c++14 but not c++1z on this
particular version of the compiler. Try to use lit boolean condition
to satisfy this constaint.
llvm-svn: 296725
This reverts commit r296712. It broke our bot.
It turns out that the test is passing with c++11 and c++14 but
not c++1z on this particular version of the compiler. Since one
job is defaulting to c++1z and the other is testing all config I'm
not sure how to fix this...
llvm-svn: 296724
This tests is failing in XCode 7.0. But Xcode 7.3 that shipped
an updated clang has this test passing. This is fixing green dragon
which runs this configuration.
llvm-svn: 296712
These tests are failing in XCode 8.0, 8.1, and 8.2, but not in Xcode
8.3. Annoyingly the version numbering for clang does not follow Xcode
and is bumped to 8.1 only in Xcode 8.3. So Xfailing apple-clang-8.0
should catch all cases here.
llvm-svn: 296704
This patch changes the CMake configuration so that it always
generates the test/lit.site.cfg file, even when testing is disabled.
This allows users to test libc++ without requiring them to have
a full LLVM checkout on their machine.
llvm-svn: 296685
This patch adds a static assertion that the specified hash meets
the requirements of an enabled hash, and it ensures that the static
assertion is evaluated before __compressed_pair is instantiated.
That way the static assertion diagnostic is emitted first.
llvm-svn: 296565
This patch fixes llvm.org/PR32097 by using the __is_abstract
builtin type-trait instead of the previous library-only implementation.
All supported compilers provide this trait. I've tested as far
back as Clang 3.2, GCC 4.6 and MSVC trunk.
llvm-svn: 296561
Summary:
`ConstexprTestTypes::NoCtors` is an aggregate type (and consequently a literal type) in C++17,
but not in C++14 since it has a base class. This patch updates the comment to accurately describe the reason for the XFAIL.
Reviewers: EricWF
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D30481
llvm-svn: 296558
The clang assertion causing these tests failing with sanitizer is fixed
in r295794. All the bots running libcxx tests should be upgraded and
running the compiler with the fix.
llvm-svn: 296385
Summary:
This patch implements [P0003R5](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html) which removes exception specifications from C++17.
The only changes to the library are removing `set_unexpected`, `get_unexpected`, `unexpected`, and `unexpected_handler`. These functions can be re-enabled in C++17 using `_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS`.
@mclow.lists what do you think about removing stuff is this way?
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D28172
llvm-svn: 295406
Summary:
This patch fixes http://llvm.org/PR31938. The description below is copy/pasted from the bug:
The standard says:
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT>>
class basic_string {
using value_type = typename traits::char_type;
// ...
basic_string(const charT* s, const Allocator& a = Allocator());
};
libc++ actually chooses to declare the constructor as
basic_string(const value_type* s, const Allocator& a = Allocator());
The implicit deduction guides from class template argument deduction make what was previously an implementation detail visible:
std::basic_string s = "foo"; // error, can't deduce charT.
The constructor in question is in the libc++ DSO, but fortunately it looks like fixing this will not result in an ABI break.
@rsmith How does this look? I did more than just the constructors mentioned in the PR, but IDK how far to take it.
Reviewers: mclow.lists, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D29863
llvm-svn: 295393
wchar_t is not as portable as char32_t. On Windows, wchar_t is
16-bytes and on Linux 32-bits. The conversion to utf8 causes the
characters to exceed the limits on char16_t, resulting in tautological
comparisons.
llvm-svn: 294917
This test explicitly is checking the behaviour of std::thread and
pthread interactions. This requires pthreads. Add an appropriate
requirement.
llvm-svn: 294903
This test validates that the lock_guard is declared variadically across
C++03 and C++11. Given the lack of stable ABI on Windows and the fact
that the RTTI encoding on Windows is different, XFAIL it on that target.
llvm-svn: 294720
When running the test under clang-cl, we do not report `__GNUC__`, which
is needed to supress the warnings which are being treated as errors.
llvm-svn: 294719
Libc++ frequently creates and uses utilities written in python.
Currently there are python modules under both libcxx/test and
libcxx/util. My goal with these changes is to consolidate them
into a single package under libcxx/utils/libcxx.
llvm-svn: 294644
Marshall Clow