Otherwise, even specifying a runtime root different from the library
we're linking against won't work -- the library we're linking against
is always used. This is undesirable if we try testing something like
linking against a recent libc++.dylib but running the tests against an
older version (the back-deployment use case).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@349171 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes a bug where functions would get exported when building with
-fvisibility=hidden and defining _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS. No
visibility annotations should be added in this case.
The new logic for _LIBCPP_EXPORTED_FROM_ABI matches that of the other visibility
annotations around it.
Differential Revision: https://reviews.llvm.org/D55664
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@349080 91177308-0d34-0410-b5e6-96231b3b80d8
Also, add tests making sure that vector and deque both catch the problem
when assertions are enabled. Otherwise, deque would segfault and vector
would never terminate.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348994 91177308-0d34-0410-b5e6-96231b3b80d8
Other standard libraries don't implement availability markup, so it doesn't
make sense to e.g. XFAIL tests based on availability markup outside of
libc++.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348871 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of an ongoing cleanup of the LIT test suite, where I'm
trying to reduce the number of configuration options. In this case,
the original intent seemed to be running the test suite with libstdc++,
but this is now supported by specifying cxx_stdlib_under_test=libstdc++.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348868 91177308-0d34-0410-b5e6-96231b3b80d8
It is unreachable because we test that the cxx_stdlib_under_test is
in the supported set of libraries elsewhere. Furthermore, this code
relied on the `use_stdlib_type`, which is never defined.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348867 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
This is a re-application of r348824, which broke the build in C++03 mode
because a test was marked as supported in C++03 when it shouldn't be.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348847 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348824 91177308-0d34-0410-b5e6-96231b3b80d8
Patch from Jordan Soyke (jsoyke@google.com)
Reviewed as D55520
This change adds a new internal class, called __value_func, that adds
a minimal subset of value-type semantics to the internal __func interface.
The change is NFC, and is cleanup for the upcoming ABI v2 function implementation (D55045).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348778 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When providing a non-const-callable comparator in a map or set, the
warning diagnostic does not include the point of instantiation of
the container that triggered the warning, which makes it difficult
to track down the problem. This commit improves the diagnostic by
placing it directly in the body of the associative container.
The same change is applied to unordered associative containers, which
had a similar problem.
Finally, this commit cleans up the forward declarations of several
map and unordered_map helpers, which are not needed anymore.
<rdar://problem/41370747>
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48955
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348529 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise, some tests would fail when a relative path was passed,
because they'd use the relative path from a different directory
than the current working directory.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348525 91177308-0d34-0410-b5e6-96231b3b80d8
The tests were marked to fail based on the 'availability' LIT feature.
However, those tests should really only be failing when we run them
against the dylibs that were deployed on macosx10.7 and macosx10.8,
which the deployment target has nothing to do with.
This caused the tests to unexpectedly pass when running the tests
with deployment target macosx10.{7,8} but running with a recent dylib.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348520 91177308-0d34-0410-b5e6-96231b3b80d8
The standard section [array.zero] requires the return value of begin()
and end() methods of a zero-sized array to be unique. Eric Fiselier
clarifies: "That unique value cannot be null, and must be properly aligned".
This patch adds checks for the first part of this clarification: unique
value returned by these methods cannot be null.
Reviewed as https://reviews.llvm.org/D55366.
Thanks to Andrey Maksimov for the patch.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348509 91177308-0d34-0410-b5e6-96231b3b80d8
The section array.zero says: "The return value of data() is unspecified".
This patch marks all checks of the array<T, 0>.data() return value as
libc++ specific.
Reviewed as https://reviews.llvm.org/D55364.
Thanks to Andrey Maksimov for the patch.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348485 91177308-0d34-0410-b5e6-96231b3b80d8
Whether an explicit instantiation declaration should be provided is not
a matter of availability markup.
This problem is exemplified by the fact that some tests were incorrectly
marked as XFAIL when they should instead have been using the definition
of streams from the headers, and hence passing, and that, regardless of
whether visibility annotations are enabled.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348436 91177308-0d34-0410-b5e6-96231b3b80d8
run_tests.py had bitrotted since it was last run (e.g. it used perl
which is now not allowed and the warning flags were out of date).
I changed it to use a different way of extracting the compile command
which is based on Soong instead of makefiles. This way is also
compatible with multiple build directories since it doesn't clobber
the source directory and doesn't require OUT_DIR == out.
This also changes run_tests.py to run the libcxxabi tests as well,
since they can be run using the same mechanism.
Bug: 120510768
Test: ./run_tests.py --bitness 32
Test: ./run_tests.py --bitness 64
Test: ./run_tests.py --bitness 64 --host
Change-Id: Id30129161f8519fa6c1bc106727326373ca9ab82
Summary:
Running the tests without availability enabled doesn't really make sense:
availability annotations allow catching errors at compile-time instead
of link-time. Running the tests without availability enabled allows
confirming that a test breaks at link-time under some configuration,
but it is more useful to instead check that it should fail at compile-time.
Always enabling availability in the lit test suite will greatly simplify
XFAILs and troubleshooting of failing tests, which is currently a giant
pain because we have these two levels of possible failure: link-time and
compile-time.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55079
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348296 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This was voted into C++20 in San Diego. Note that there was a revision
D0318R2 which did include unwrap_reference_t, but we mistakingly voted
P0318R1 into the C++20 Working Draft (which does not include
unwrap_reference_t). This patch implements D0318R2, which is what
we'll end up with in the Working Draft once this mistake has been
fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54485
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348138 91177308-0d34-0410-b5e6-96231b3b80d8
The test was previously marked as unsupported on all Apple platforms, when
we really just want to mark it as unsupported for previously shipped dylibs
on macosx.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347920 91177308-0d34-0410-b5e6-96231b3b80d8
