Summary: This is my attempt to work around the C1XX bug described to me by @BillyONeal.
Reviewers: BillyONeal, STL_MSFT, CaseyCarter
Reviewed By: BillyONeal
Subscribers: cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D31260
llvm-svn: 298554
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
Clang doesn't produce gcov compatible coverage files. This
causes lcov to break because it uses gcov by default. This
patch switches lcov to use llvm-cov as the gcov-tool.
Unfortunatly llvm-cov doesn't provide a gcov like interface by
default so it won't work with lcov. However `llvm-cov gcov` does.
For this reason we generate 'llvm-cov-wrapper' script that always
passes the gcov flag.
llvm-svn: 297553
basic_string::replace() has the below line
__sz += __n2 - __n1;
which fails overflow checks if __n1 > __n2, as the negative result
from the subtraction then overflows the original __sz when added to
it.
This behavior is valid as unsigned integer overflow is defined to wrap
around the maximum value and that produces the correct final value for
__sz. Therefore, we disable this check on this function.
llvm-svn: 297355
Put proper guards around _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS.
No functional change on non-Windows. Avoids incorrect macro redefinition
on Windows.
llvm-svn: 297330
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
Summary:
Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them.
This patch adds the CMake option `-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS` which defaults no `ON` unless `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON` is specified.
Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, mgorny, rmaprath
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30516
llvm-svn: 296802
Summary:
Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some
of their members exported, otherwise we have a lot of link errors when
linking against a libc++ built with hidden visibility. This also makes
_LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it
already exports members.
With this change made, any template methods of a class marked
_LIBCPP_TYPE_VIS will also get default visibility when instantiatied,
which is not desirable for clients of libc++ headers who wish to control
their visibility; this is the same issue as PR30642. Annotate all
problematic methods with an explicit visibility specifier to avoid this.
The problematic methods were found by running bad-visibility-finder [1]
against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The
small methods were marked for inlining; the larger ones hidden.
[1] https://github.com/smeenai/bad-visibility-finder
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25208
llvm-svn: 296732
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
D29157 will make explicit template instantiations expand to default
visibility, at which point these method templates will need to be
explicitly marked hidden visibility to avoid leaking into other DSOs.
Unfortunately, because of clang PR32114, they must be marked inline (in
conjunction with `-fvisibility-inlines-hidden`) to actually hide them,
since clang doesn't respect the hidden visibility annotation.
Since this involves an ABI change, mark these methods inline in a
separate change, so that the ABI changes can be reviewed separately and
verified to be safe.
Differential Revision: https://reviews.llvm.org/D30523
llvm-svn: 296729
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
This reverts SVN r295329. Although `__libcpp_thread_sleep_for` should
be alertable, the implementation causes a large regression in the test
suite. Add a FIXME item there for now to get the test suite in a better
state before attempting to fix that behaviour.
llvm-svn: 295561
When building with MSVCRT, we need to manually provide the type
promoting overloads to allow the correct type deduced invocation for
signbit(Int) and fpclassify(int).
llvm-svn: 295559
The path would previously get an extra leading space as the arguments
would be parsed when generating the final command to run. Pretokenise
the arguments to permit proper quoting of the paths. This avoids a
number of ignoring non-existent path warnings from clang.
llvm-svn: 295511
GCC 7.0.1 started warning that __attribute__((__strong__)) is depricated.
This patch switches to using inline namespace with GCC instead. I believe
this wasn't done originally in order to support older GCC versions w/o
support for inline namespaces, or because earlier versions of GCC warned
users that the STL was using an inline namespace (even though it shouldn't affect users).
However I believe all of the above problems are gone for GCC 4.9 and greater.
Therefore switching to using inline namespaces instead of using __strong__
is the most correct behavior.
llvm-svn: 295428
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
On Windows, we were using `Sleep` which is not alertable. This means
that if the thread was used for a user APC or WinProc handling and
thread::sleep was used, we could potentially dead lock. Use `SleepEx`
with an alertable sleep, resuming until the time has expired if we are
awoken early.
llvm-svn: 295329
clang cannot properly handle __declspec and __attribute__ on classes
right now. This prevents the shared_mutex tests from working. Disable
the use of the annotation on COFF targets.
llvm-svn: 294958
Pull in the math functions from ucrt 14+ after auditing the library. It
seems that they are now complete for C99 math. Fixes more windows
tests!
llvm-svn: 294918
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
The newer versions of ucrt have the math routines. Use the CRT version
to determine if we should include the math routines. Fixes two tests
for Windows.
llvm-svn: 294899
This recommits r294707 with additional fixes. The main difference is
libc++ now correctly builds without any ABI library.
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294730
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
When running the tests on Windows with a debug build, _DEBUG must be
added to the flags prior to the -target as the forced inclusion of a
header will prevent the compile test for the flag to fail.
llvm-svn: 294716
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294707
This covers how to build libc++ for Windows. This allows others to
replicate the MS ABI style build for libc++. It only depends on msvcrt
as it uses the Windows threading model and the Windows ABI and can serve
as an ABI compatible replacement for msvcprt.
llvm-svn: 294705
Summary:
Libcxx will define its own max_align_t when it is not available. However, the
availability checks today only check for Clang's definition and GCC's
definition. In particular, it does not check for musl's definition, which is the
same as GCC's but guarded with a different macro.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: chandlerc, cfe-commits
Differential Revision: https://reviews.llvm.org/D28478
llvm-svn: 294683
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
A static assertion was misfiring since it checked
is_callable<Visitor, decltype(__variant_alt<T>.value)>. However
the decltype expression doesn't capture the value category as
required. This patch applies extra braces to decltype to fix
that.
llvm-svn: 294612
Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.
Differential revision: https://reviews.llvm.org/D29630
Reviewers: EricWF, joerg
llvm-svn: 294573
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29575
llvm-svn: 294553
Filesystems are not required to maintain a hard link count consistent
with number of subdirectories. For example, on btrfs all directories
have nlink==1. Account for that in the test.
Differential Revision: https://reviews.llvm.org/D29706
llvm-svn: 294431
Recently I turned on libc++'s debug mode assertions when
CMake is configured with -DLIBCXX_ENABLE_ASSERTIONS=ON. This
change exposed assertion failures caused by bugs in filesystem.
This patch fixes those failures.
The first bug was that `PathParser` was using front()/back()
on empty string views in order to get the address of the character.
However this is UB on empty strings. Those operations now use data()
to obtain the pointer.
The second bug was that directory_iterator attempted to capture errno when it
was unset and there was an assertion to detect this.
llvm-svn: 294360
This really should get identified properly by the compiler to convert to
a NVRO, but compress the code anyways. This makes the implementation
identical to directory_iterator.cpp
llvm-svn: 294270
In addition to the PR for LWG 2773 this patch also ensures
that each of std::ignores constructors or assignment operators
are constexpr.
llvm-svn: 294165
Marshall Clow