* Silence unused-local-typedef warnings: `map.cons/assign_initializer_list.pass.cpp` (and the `set.cons` variant) uses a local typedef only within `LIBCPP_ASSERT`s, so clang diagnoses it as unused when testing non-libc++.
* Add missing include: `c.math/abs.pass.cpp` uses `std::numeric_limits` but failed to `#include <limits>`.
* Don't test non-type: A "recent" change to `meta.trans.other/underlying_type.pass.cpp` unconditionally tests the type `F` which is conditionally defined.
* Use `hash<long long>` instead of `hash<short>` with `int` in `unordered_meow` deduction guide tests to avoid truncation warnings.
* Convert `3.14` explicitly in `midpoint.float.pass` since MSVC incorrectly diagnoses `float meow = 3.14;` as truncating.
Differential Revision: https://reviews.llvm.org/D68681
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374248 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68343
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374116 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that r374056 broke _some_ build bots again, specifically
the ones using sanitizers. Instead of trying to link the right system
libraries to the benchmarks bit-by-bit, let's just link exactly the
system libraries that libc++ itself needs.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374079 91177308-0d34-0410-b5e6-96231b3b80d8
We tried doing that previously (in r373487) and failed (reverted in
r373506) because the benchmarks needed to link against system libraries
and relied on libc++'s dependencies being propagated. Now that this has
been fixed (in r374053), this commit marks the system libraries as
PRIVATE dependencies of libc++.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374056 91177308-0d34-0410-b5e6-96231b3b80d8
Since the benchmarks build with -nostdlib, they need to manually link
against some system libraries that are used by the benchmarks and the
GoogleBenchmark library itself.
Previously, we'd rely on the fact that these libraries were linked
through the PUBLIC dependencies of cxx_shared/cxx_static. However,
if we were to make these dependencies PRIVATE (as they should be
because they are implementation details of libc++), the benchmarks
would fail to link. This commit remediates that.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374053 91177308-0d34-0410-b5e6-96231b3b80d8
It's better style to use PRIVATE when linking libraries to executables,
and it doesn't make a difference since executables don't need to propagate
their link-time dependencies anyway.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374050 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: In my last patch (D67675) I forgot a few variadics. This patch removes the remaining make_shared and allocate_shared C++03 variadics.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68000
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373971 91177308-0d34-0410-b5e6-96231b3b80d8
If you explicitly set LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY to OFF, your
project will fail to configure because the cxx_experimental target
doesn't exist.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373809 91177308-0d34-0410-b5e6-96231b3b80d8
Also, set those flags for the cxx_experimental target. Otherwise,
cxx_experimental doesn't build properly when neither the static nor
the shared library is compiled (yes, that is a weird setup).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373808 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The current version of the pretty printers are not python3 compatible,
so turn them off by default until sufficiently improved.
Reviewers: MaskRay, tamur
Subscribers: mgorny, christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68477
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373796 91177308-0d34-0410-b5e6-96231b3b80d8
It appears that those need to be propagated to targets that use libc++
as well, otherwise they don't build properly.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373773 91177308-0d34-0410-b5e6-96231b3b80d8
The first commit removed the workaround in a old script.
This patch removes it in the file actually used by the bots.
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373653 91177308-0d34-0410-b5e6-96231b3b80d8
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373650 91177308-0d34-0410-b5e6-96231b3b80d8
This allows propagating the include automatically to targets that
depend on one of the libc++ targets such as the benchmarks. Note
that the GoogleBenchmark build itself still needs to manually specify
the -include, since I don't know of any way to have an external project
link against one of the libc++ targets (which would propagate the -include
automatically).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373631 91177308-0d34-0410-b5e6-96231b3b80d8
In both Python 2 and Python 3, gdb.Value.string returns a 'str'. We just
need to delete a `encode("utf-8")` which would return a 'bytes' in
Python 3.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373570 91177308-0d34-0410-b5e6-96231b3b80d8
This commit follows the trend of doing things per-target instead of
modifying the C++ flags globally. It does so for visibility-related
flags, other basic build flags and Windows-specific flags.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373517 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of a larger shift to move to per-target settings and
eradicate global variables from the CMake build. I'm starting small
with warnings only because those are easy to transition over and I
want to see how it pans out, but we can handle all flags like exceptions
and RTTI in the future.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373511 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out the benchmarks need to link against those libraries
explicitly too, so CMake's propagation of PUBLIC dependencies is
used.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373506 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I haven't managed a small reproduction for this bug, it involves
complicated and deeply nested data structures with a wide variety
of pretty printers. But in general, we shouldn't be combining
gdb's command line interface (via gdb.execute) with pretty-printers.
Subscribers: christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68306
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373402 91177308-0d34-0410-b5e6-96231b3b80d8
In reality, this workaround is for the fact that LIBCXX_CXX_ABI=libcxxabi
can't be specified on Linux, since libc++abi isn't shipped with the system.
Since the build bots explicitly specify LIBCXX_CXX_ABI=libcxxabi, they fail
unless we apply the workaround.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373385 91177308-0d34-0410-b5e6-96231b3b80d8
I tried applying D63883 three times and could never get around to
making it work. I'm giving up on that for now, but soon this should
be irrelevant anyway since all builds will move to the monorepo
(where we're always using the in-tree libc++abi unless explicitly
specified otherwise).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373384 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
This was previously committed as r372778 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373092 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
This was previously committed as r372777 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372983 91177308-0d34-0410-b5e6-96231b3b80d8
Users should only get the assert() macros if they explicitly include
them.
Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372963 91177308-0d34-0410-b5e6-96231b3b80d8
We don't support GCC 4 and older according to the documentation, so
we should pretend it doesn't exist.
This is a re-application of r372787.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372916 91177308-0d34-0410-b5e6-96231b3b80d8
This declaration was previously missing despite appearing in the
synopsis. Users are still required to include <ostream> to get the
definition of the streaming operator.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372909 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372778 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372777 91177308-0d34-0410-b5e6-96231b3b80d8
