| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
associative containers
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
llvm-svn: 348529
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 348525
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 348520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
0>.end()
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.
llvm-svn: 348509
|
|
|
|
|
|
| |
Some people are still running the test suite using AppleClang 9.
llvm-svn: 348507
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 348485
|
|
|
|
| |
llvm-svn: 348437
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 348436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 348296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 348138
|
|
|
|
|
|
| |
numeric_limits<char8_t> is valid and sane. (second try)
llvm-svn: 347930
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 347920
|
|
|
|
| |
llvm-svn: 347908
|
|
|
|
|
|
| |
numeric_limits<char8_t> is valid and sane.
llvm-svn: 347904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
std::bad_array_length was added by n3467, but this never made it into C++.
This commit removes the definition of std::bad_array_length from the headers
AND from the shared library. See the comments in the ABI changelog for details
about the ABI implications of this change.
Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF
Subscribers: christof, jkorous, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54804
llvm-svn: 347903
|
|
|
|
|
|
| |
Those tests are a real pain to tweak.
llvm-svn: 347875
|
|
|
|
|
|
|
|
|
|
|
| |
`_LIBCPP_ALIGNOF`. "
This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12.
The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.
llvm-svn: 347816
|
|
|
|
| |
llvm-svn: 347790
|
|
|
|
| |
llvm-svn: 347789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: EricWF
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 347787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
std::dynarray had been proposed for C++14, but it was pulled out from C++14
and there are no plans to standardize it anymore.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54801
llvm-svn: 347783
|
|
|
|
|
|
| |
enabled
llvm-svn: 347780
|
|
|
|
| |
llvm-svn: 347765
|
|
|
|
| |
llvm-svn: 347711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When the Xcode Command Line tools are not installed but CMAKE_OSX_SYSROOT is
set, we would try to re-export symbols from the libc++abi.dylib shipped in
the sysroot, which does not exist. This commit changes the build on OS X to
always re-export symbols from the explicit re-export lists, which doesn't
change depending on what system you're building on, and is therefore much
less flaky.
Reviewers: EricWF, mclow.lists
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54595
llvm-svn: 347708
|
|
|
|
| |
llvm-svn: 347672
|
|
|
|
|
|
|
| |
This attribute should appear only on the first declaration. This
patch cleans up <string> by removing the attribute on redeclarations.
llvm-svn: 347608
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds an implementation of __resize_default_init as
described in P1072R2. Additionally, it uses it in filesystem to
demonstrate its intended utility.
Once P1072 lands, or if it changes it's interface, I will adjust
the internal libc++ implementation to match.
llvm-svn: 347589
|
|
|
|
|
|
|
|
|
|
| |
In r339743, I marked several aligned allocation tests as downright
unsupported on macosx in an attempt to unbreak the build. It turns
out that marking them as unuspported whenever we're on OS X is way
too coarse grained. This commit marks the tests as XFAIL with more
granularity.
llvm-svn: 347585
|
|
|
|
|
|
|
|
|
|
|
| |
The test was marked as failing whenever the deployment target was 10.12
or older, but in reality the test passes when the deployment target is
10.12 on recent Clangs. This happens because only older clangs do not
honor the -faligned-allocation flag, which disables any availability
error related to aligned allocation support, regardless of the
deployment target.
llvm-svn: 347580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In PR39232, we noticed that some variant tests started failing in C++2a mode
with recent Clangs, because the rules for literal types changed in C++2a. As
a result, a temporary fix was checked in (enabling the test only in C++17).
This commit is what I believe should be the long term fix: I removed the
tests that checked constexpr default-constructibility with a weird type
from the tests for index() and valueless_by_exception(), and instead I
added tests for those using an obviously literal type in the test for the
default constructor.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, arphaman, libcxx-commits, rsmith
Differential Revision: https://reviews.llvm.org/D54767
llvm-svn: 347568
|
|
|
|
| |
llvm-svn: 347477
|
|
|
|
|
|
|
|
|
|
|
| |
This is a revert of r347421, except I'm using the with_system_cxx_lib
lit feature instead of availability to mark the test as unsupported
(because the problem is a bug in the dylib itself). In r347421, I said
I wasn't able to reproduce the issue and that's why I was removing it:
this was because I ran lit slightly wrong. The problem mentioned really
exists.
llvm-svn: 347475
|
|
|
|
| |
llvm-svn: 347473
|
|
|
|
|
|
|
|
| |
We used to print a Python list corresponding to the command. It is more
useful to print the joined string so it can be copy/pasted directly when
a test fails.
llvm-svn: 347471
|
|
|
|
| |
llvm-svn: 347461
|
|
|
|
|
|
| |
use_system_cxx_lib
llvm-svn: 347435
|
|
|
|
|
|
|
|
| |
We don't support mac OS 10.6 and older anymore, so this macro can never
be defined. This bit of code had been added in D28931 as a fix for
PR31448, but it doesn't seem necessary anymore.
llvm-svn: 347427
|
|
|
|
|
|
|
|
|
|
|
|
| |
The iterator types for different specializations of containers with the
same element type but different allocators are not required to be
convertible. This patch makes the test to take the iterator type from
the same container specialization as the created container.
Reviewed as https://reviews.llvm.org/D54806.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347423
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wasn't able to reproduce the issue referred to by the comment using
the libc++'s shipped with mac OS X 10.7 and 10.8, so I assume this may
have been fixed in a function that is now shipped in the headers. In
that case, the tests will pass no matter what dylib we're using.
In the worst case, some test bots will start failing and I'll understand
why I was wrong, and I can create an actual lit feature for it. Note
that I could just leave this test alone, but this change is on the path
towards eradicating vendor-specific availability markup from the test
suite.
llvm-svn: 347421
|
|
|
|
| |
llvm-svn: 347416
|
|
|
|
|
|
|
| |
Otherwise, Clang complains about internal_linkage not being applied to the
first declaration of the operator (and rightfully so).
llvm-svn: 347400
|
|
|
|
|
|
|
|
|
|
|
|
| |
r347395 changed the ABI list on Linux, but two of those symbols are still
being exported from the shared object:
_ZSt18make_exception_ptrINSt3__112future_errorEESt13exception_ptrT_
_ZNSt3__1plIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_12basic_stringIT_T0_T1_EERKS9_PKS6_
This commit makes sure those symbols are not exported, as they should be.
llvm-svn: 347399
|
|
|
|
| |
llvm-svn: 347396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit marks a few functions as hidden and removes them from the ABI list
on Linux such that libc++ can be built with -fvisibility=hidden. The functions
marked as hidden by this patch were exported from the shared object only
because they were implicitly instantiated function templates. It is safe
to stop exporting those symbols from the shared object because nobody could
actually depend on them: implicit instantiations are not taken from shared
objects.
The symbols removed in this commit are basically the same that had been
removed in https://reviews.llvm.org/D53868, but that patch had to be reverted
because it broke the build (because the functions were not marked as hidden
like this patch does).
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54639
llvm-svn: 347395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Avoid buffer overflow by replacing the pointer interface with an array reference interface in C++2a.
Tentatively ready on Batavia2018.
https://wg21.link/lwg2499
https://wg21.link/p0487
Reviewers: mclow.lists, ldionne, EricWF
Reviewed By: ldionne
Subscribers: libcxx-commits, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D51268
llvm-svn: 347377
|
|
|
|
|
|
|
| |
The '-faligned-allocation' flag uses a feature with the same name (with a
leading dash).
llvm-svn: 347367
|
|
|
|
|
|
| |
Aligning everything makes what we're doing more obvious.
llvm-svn: 347363
|
|
|
|
| |
llvm-svn: 347362
|
|
|
|
|
|
| |
P0482 (support for char8_t). Comment out those bits until we implement the corresponding bits in libc++
llvm-svn: 347360
|