The "const" pointer typedefs such as "__node_const_pointer" and
"__node_base_const_pointer" are identical to their non-const pointer types.
This patch changes all usages of "const" pointer type names to their respective
non-const typedef.
Since "fancy pointers to const" cannot be converted back to a non-const pointer
type according to the allocator requirements it is important that we never
actually use "const" pointers.
Furthermore since "__node_const_pointer" and "__node_pointer" already
name the same type, it's very confusing to use both names. Especially
when defining const/non-const overloads for member functions.
llvm-svn: 261419
This patch is very similar to r260431.
This patch is the first in a series of patches that's meant to better
support map. map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __tree about this
special value_type.
This patch creates a "__tree_node_types" traits class that contains
all of the typedefs needed by the associative containers and their iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "map"'s value type.
Although the associative containers already supported incomplete types, this
patch makes it official by adding tests.
This patch will be followed up shortly with various cleanups within __tree and
fixes for various map bugs and problems.
llvm-svn: 261416
Summary:
This bug was originally fixed in http://reviews.llvm.org/D7201.
However it was broken again by the fix to https://llvm.org/bugs/show_bug.cgi?id=22605.
This patch re-fixes __wrap_iter with GCC by providing a forward declaration of <vector> before the friend declaration in __wrap_iter.
This patch avoids the issues in PR22605 by putting canonical forward declarations in <iosfwd> and including <iosfwd> in <vector>.
<iosfwd> was chosen as the canonical forward declaration headers for the following reasons:
1. `<iosfwd>` is small with almost no dependancies.
2. It already forward declares `std::allocator`
3. It is already included in `<iterator>` which we need to fix the GCC bug.
This patch fixes the test "gcc_workaround.pass.cpp"
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16345
llvm-svn: 261382
Summary:
According to the C++ standard <stdbool.h> isn't allowed to define `true` `false` or `bool`. However these macros are sometimes defined by the compilers `stdbool.h`.
Clang defines the macros whenever `__STRICT_ANSI__` isn't defined (ie `-std=gnu++11`).
New GCC versions define the macros in C++03 mode only, older GCC versions (4.9 and before) always define the macros.
This patch adds a wrapper header for `stdbool.h` that undefs the required macros.
Reviewers: mclow.lists, rsmith, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16346
llvm-svn: 261381
This is one part of many of a locale refactor. See
http://reviews.llvm.org/D17146 for an idea of where this is going.
For the locale refactor, the locale management functions (newlocale,
freelocale, uselocale) are needed in a separate header from the various _l
functions. This is because some platforms implement the _l functions in terms
of a locale switcher RAII helper, and the locale switcher RAII helper needs
the locale management functions. This patch helps pave the way by getting all
the functions in the right files, so that later diffs aren't completely
horrible.
The "do-nothing" / "nop" locale functions are also useful on their own for
other lightweight platforms. Putting these nop implementations in
support/xlocale should enable code sharing.
Unfortunately, I have no access to a newlib system to build and test with, so
this change has been made blind.
Reviewed: http://reviews.llvm.org/D17382
llvm-svn: 261231
This is one part of many of a locale refactor. See
http://reviews.llvm.org/D17146 for an idea of where this is going.
For the locale refactor, the locale management functions (newlocale,
freelocale, uselocale) are needed in a separate header from the various _l
functions. This is because some platforms implement the _l functions in terms
of a locale switcher RAII helper, and the locale switcher RAII helper needs
the locale management functions. This patch helps pave the way by getting all
the functions in the right files, so that later diffs aren't completely
horrible.
Unfortunately, I have no access to an AIX machine to build with, so this change
has been made blind. Also, the original author (Xing Xue) does not appear to
have a Phabricator account.
Reviewed: http://reviews.llvm.org/D17380
llvm-svn: 261230
Summary:
On glibc, the bits used for the various character classes is endian dependant
(see _ISbit() in ctypes.h) but __regex_word does not account for this and uses
a spare bit that isn't spare on big-endian. On big-endian, it overlaps with the
bit for graphic characters which causes '-', '@', etc. to be considered a word
character.
Fixed this by defining the value using _ISbit(15) on MIPS glibc systems. We've
restricted this to MIPS for now to avoid the risk of introducing failures in
other targets.
Fixes PR26476.
Reviewers: hans, mclow.lists
Subscribers: dsanders, cfe-commits
Differential Revision: http://reviews.llvm.org/D17132
llvm-svn: 261088
This should fix PR26631, PR26622 and has the nice property that the addition
of the CheckLibcxxAtomic.cmake module acts as an NFC on the platforms of the
reporters (at least for the time being).
As these bug reports explain, CMake fails the atomic check because the
include headers might not exist in the host environment. We could
potentially point to the headers provided by libcxx itself.
llvm-svn: 260961
functions, ask it whether it did provide them after the fact. Some versions of
glibc fail to compile if you make this request and don't also claim to be at
least GCC 4.3.
llvm-svn: 260622
unordered_map's allocator may only be used to construct objects of 'value_type',
or in this case 'pair<const Key, Value>'. In order to respect this requirement
in operator[], which requires default constructing the 'mapped_type', we have
to use pair's piecewise constructor with '(tuple<Kep>, tuple<>)'.
Unfortunately we still need to provide a fallback implementation for C++03
since we don't have <tuple>. Even worse this fallback is the last remaining
user of '__hash_map_node_destructor' and '__construct_node_with_key'.
llvm-svn: 260601
This re-applies commit r260235. However, this time we add -gcc-toolchain
to the compiler's flags when the user has specified the LIBCXX_GCC_TOOLCHAIN
variable.
llvm-svn: 260515
This patch is fairly large and contains a number of changes. The main change
is teaching '__hash_table' how to handle '__hash_value_type'. Unfortunately
this change is a rampant layering violation, but it's required to make
unordered_map conforming without re-writing all of __hash_table.
After this change 'unordered_map' can delegate to '__hash_table' in almost all cases.
The major changes found in this patch are:
* Teach __hash_table to differentiate between the true container value type
and the node value type by introducing the "__container_value_type" and
"__node_value_type" typedefs. In the case of unordered_map '__container_value_type'
is 'pair<const Key, Value>' and '__node_value_type' is '__hash_value_type'.
* Switch almost all overloads in '__hash_table' previously taking 'value_type'
(AKA '__node_value_type) to take '__container_value_type' instead. Previously
'pair<K, V>' would be implicitly converted to '__hash_value_type<K, V>' because
of the function signature.
* Add '__get_key', '__get_value', '__get_ptr', and '__move' static functions to
'__key_value_types'. These functions allow '__hash_table' to unwrap
'__node_value_type' objects into '__container_value_type' and its sub-parts.
* Pass '__hash_value_type::__value_' to 'a.construct(p, ...)' instead of
'__hash_value_type' itself. The C++14 standard requires that 'a.construct()'
and 'a.destroy()' are only ever instantiated for the containers value type.
* Remove '__hash_value_type's constructors and destructors. We should never
construct an instance of this type.
(TODO this is UB but we already do it in plenty of places).
* Add a generic "try-emplace" function to '__hash_table' called
'__emplace_unique_key_args(Key const&, Args...)'.
The following changes were done as cleanup:
* Introduce the '_LIBCPP_CXX03_LANG' macro to be used in place of
'_LIBCPP_HAS_NO_VARIADICS' or '_LIBCPP_HAS_NO_RVALUE_REFERENCE'.
* Cleanup C++11 only overloads that assume an incomplete C++11 implementation.
For example this patch removes the __construct_node overloads that do
manual pack expansion.
* Forward 'unordered_map::emplace' to '__hash_table' and remove dead code
resulting from the change. This includes almost all
'unordered_map::__construct_node' overloads.
The following changes are planed for future revisions:
* Fix LWG issue #2469 by delegating 'unordered_map::operator[]' to use
'__emplace_unique_key_args'.
* Rewrite 'unordered_map::try_emplace' in terms of '__emplace_unique_key_args'.
* Optimize '__emplace_unique' to call '__emplace_unique_key_args' when possible.
This prevent unneeded allocations when inserting duplicate entries.
The additional follow up work needed after this patch:
* Respect the lifetime rules for '__hash_value_type' by actually constructing it.
* Make '__insert_multi' act similar to '__insert_unique' for objects of type
'T&' and 'T const &&' with 'T = __container_value_type'.
llvm-svn: 260514
This patch is fairly large and contains a number of changes. The main change
is teaching '__hash_table' how to handle '__hash_value_type'. Unfortunately
this change is a rampant layering violation, but it's required to make
unordered_map conforming without re-writing all of __hash_table.
After this change 'unordered_map' can delegate to '__hash_table' in almost all cases.
The major changes found in this patch are:
* Teach __hash_table to differentiate between the true container value type
and the node value type by introducing the "__container_value_type" and
"__node_value_type" typedefs. In the case of unordered_map '__container_value_type'
is 'pair<const Key, Value>' and '__node_value_type' is '__hash_value_type'.
* Switch almost all overloads in '__hash_table' previously taking 'value_type'
(AKA '__node_value_type) to take '__container_value_type' instead. Previously
'pair<K, V>' would be implicitly converted to '__hash_value_type<K, V>' because
of the function signature.
* Add '__get_key', '__get_value', '__get_ptr', and '__move' static functions to
'__key_value_types'. These functions allow '__hash_table' to unwrap
'__node_value_type' objects into '__container_value_type' and its sub-parts.
* Pass '__hash_value_type::__value_' to 'a.construct(p, ...)' instead of
'__hash_value_type' itself. The C++14 standard requires that 'a.construct()'
and 'a.destroy()' are only ever instantiated for the containers value type.
* Remove '__hash_value_type's constructors and destructors. We should never
construct an instance of this type.
(TODO this is UB but we already do it in plenty of places).
* Add a generic "try-emplace" function to '__hash_table' called
'__emplace_unique_key_args(Key const&, Args...)'.
The following changes were done as cleanup:
* Introduce the '_LIBCPP_CXX03_LANG' macro to be used in place of
'_LIBCPP_HAS_NO_VARIADICS' or '_LIBCPP_HAS_NO_RVALUE_REFERENCE'.
* Cleanup C++11 only overloads that assume an incomplete C++11 implementation.
For example this patch removes the __construct_node overloads that do
manual pack expansion.
* Forward 'unordered_map::emplace' to '__hash_table' and remove dead code
resulting from the change. This includes almost all
'unordered_map::__construct_node' overloads.
The following changes are planed for future revisions:
* Fix LWG issue #2469 by delegating 'unordered_map::operator[]' to use
'__emplace_unique_key_args'.
* Rewrite 'unordered_map::try_emplace' in terms of '__emplace_unique_key_args'.
* Optimize '__emplace_unique' to call '__emplace_unique_key_args' when possible.
This prevent unneeded allocations when inserting duplicate entries.
The additional follow up work needed after this patch:
* Respect the lifetime rules for '__hash_value_type' by actually constructing it.
* Make '__insert_multi' act similar to '__insert_unique' for objects of type
'T&' and 'T const &&' with 'T = __container_value_type'.
llvm-svn: 260513
static_cast of a pointer to object before the start of the object's
lifetime has undefined behavior.
This code triggers CFI warnings.
This change replaces C-style casts with reinterpret_cast, which is
fine per the standard, add applies an attribute to silence CFI (which
barks on reinterpret_cast, too).
llvm-svn: 260441
This time I kept <ext/hash_map> working!
This patch is the first in a series of patches that's meant to better
support unordered_map. unordered_map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __hash_table about this
special value_type.
This patch creates a "__hash_node_types" traits class that contains
all of the typedefs needed by the unordered containers and it's iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "unordered_map"'s value type.
As a result of this change all of the unordered containers now all support
incomplete types.
As a drive-by fix I changed the difference_type in __hash_table to always
be ptrdiff_t. There is a corresponding change to size_type but it cannot
take affect until an ABI break.
This patch will be followed up shortly with fixes for various unordered_map
bugs and problems.
llvm-svn: 260431
Operating systems that are not unix-like are unlikely to have access to
catopen. Instead of black-listing each one, we now filter out all non-unix
operating systems first. We then exclude the unix-like operating systems
that don't have catopen. _WIN32 counts as a unix-like operating system
because of cygwin.
http://reviews.llvm.org/D16639
llvm-svn: 260381
<string.h> and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from <wchar.h> to
provide a const-correct overload set even when the underlying C library does
not.
This change adds a new macro, _LIBCPP_PREFERRED_OVERLOAD, which (if defined)
specifies that a given overload is a better match than an otherwise equally
good function declaration without the overload. This is implemented in modern
versions of Clang via __attribute__((enable_if)), and not elsewhere.
We use this new macro to define overloads in the global namespace for these
functions that displace the overloads provided by the C library, unless we
believe the C library is already providing the correct signatures.
llvm-svn: 260337
This reverts commit r260235. It breaks LLVM's bootstrap when building
with a -gcc-toolchain and the system's gcc installation does not provide
the libatomic library and its headers. We should check whether
LIBCXX_GCC_TOOLCHAIN is set and adjust the flags accordingly.
llvm-svn: 260323
Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.
Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16613
llvm-svn: 260235
Avoid the developer warnings from cmake when configuring libc++ as part of the
LLVM layout. Setup the custom macro paths earlier to re-use the detection logic
prior to setting the project properties.
llvm-svn: 260071
This patch is the first in a series of patches that's meant to better
support unordered_map. unordered_map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __hash_table about this
special value_type.
This patch creates a "__hash_node_types" traits class that contains
all of the typedefs needed by the unordered containers and it's iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "unordered_map"'s value type.
As a result of this change all of the unordered containers now all support
incomplete types.
As a drive-by fix I changed the difference_type in __hash_table to always
be ptrdiff_t. There is a corresponding change to size_type but it cannot
take affect until an ABI break.
This patch will be followed up shortly with fixes for various unordered_map
fixes.
llvm-svn: 260012
Rather than crashing in match_results::format() when a reference to a
marked subexpression is out of range, format the subexpression as empty
(i.e., replace it with an empty string). Note that
match_results::operator[]() has a range-check and returns a null match
in this case, so this just re-uses that logic.
llvm-svn: 259682
Instead of excluding all known operating systems that are not derived from BSD,
I now include all operating systems that claim to be derived from BSD.
Hopefully, that will make it so that this check doesn't need to change for
every new operating system that comes along.
http://reviews.llvm.org/D16634
llvm-svn: 259193
Summary:
This is a workaround to a clang bug which causes libcxx tests to fail in the 3.8
release. The clang bug is currently being investigated. It seems that clang
does not stop after frontend errors when using -verify and -fno-integrated-as
(or when this is the default). This patch adds -fsyntax-only to prevent GAS
from being called, fixing the libcxx failures.
PR26277
Patch by Eric Fiselier
Reviewers: mclow.lists, hans, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16584
llvm-svn: 259046
Summary:
These are the tests that didn't fail in the release candidate because they were
covered by another 'REQUIRES' directive.
Reviewers: mclow.lists, hans, bcraig, EricWF
Subscribers: EricWF, dim, cfe-commits
Differential Revision: http://reviews.llvm.org/D16408
llvm-svn: 258920
Per discussion with Eric and Joerg, this commit removes -Wpadded to
silence the warning about the padding inserted at the tail of struct
_Rep_base.
rdar://problem/23932550
llvm-svn: 258900
Summary:
This patch is similar to the <list> fix but it has a few differences. This patch doesn't use a `__link_pointer` typedef because we don't need to change the linked list pointers because `forward_list` never stores a `__forward_begin_node` in the linked list itself.
The issue with `forward_list` is that the iterators store pointers to `__forward_list_node` and not `__forward_begin_node`. This is incorrect because `before_begin()` and `cbefore_begin()` return iterators that point to a `__forward_begin_node`. This means we incorrectly downcast the `__forward_begin_node` pointer to a `__node_pointer`. This downcast itself is sometimes UB but it cannot be safely removed until ABI v2. The more common cause of UB is when we deference the downcast pointer. (for example `__ptr_->__next_`). This can be fixed without an ABI break by upcasting `__ptr_` before accessing it.
The fix is as follows:
1. Introduce a `__iter_node_pointer` typedef that works similar to `__link_pointer` in the last patch. In ABI v2 it is always a typedef for `__begin_node_pointer`.
2. Change the `__before_begin()` method to return the correct pointer type (`__begin_node_pointer`),
Previously it incorrectly downcasted the `__forward_begin_node` to a `__node_pointer` so it could be used to constructor the iterator types.
3. Change `__forward_list_iterator` and `__forward_list_const_iterator` in the following way:
1. Change `__node_pointer __ptr_;` member to have the `__iter_node_pointer` type instead.
2. Add additional private constructors that accept `__begin_node_pointer` in addition to `__node_pointer` and then correctly cast them to the stored `__iter_node_pointer` type.
3. Add `__get_begin()` and `__get_node_unchecked()` accessor methods that correctly cast `__ptr_` to the expected pointer type. `__get_begin()` is always safe to use and should be
preferred. `__get_node_unchecked()` can only be used on a deferencible iterator.
4. Replace direct access to `__forward_list_iterator::__ptr_` with the safe accessor methods.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15836
llvm-svn: 258888
This reverts commit r258575. EricWF sent me an email (no link since it
was off-list) requesting to review this pre-commit instead of
post-commit.
llvm-svn: 258625
An upcoming commit will add an optimization to insert() that avoids
unnecessary mallocs when we can safely extract the key type. This
commit shares code between emplace() and insert():
- if emplace() is given a single argument, and
- value_type is constructible from that argument
so that we have a single code path for the two.
I also updated the debug version of emplace_hint() to defer to
emplace(), like the non-debug version does.
In both cases, there should be NFC here.
llvm-svn: 258575
Rename the version of __construct_node() that takes a hash as an
argument to __construct_node_hash(), and use perfect-forwarding when
Rvalue references are available. The primary motivation is to allow
other types through, since unordered_map's value_type is different from
__hash_table's value_type -- a follow-up will take advantage of this --
but the rename is general "goodness".
There should be no functionality change here (aside from enabling the
follow-up).
llvm-svn: 258511
"__as_link()" can only be used safely on "__list_node" objects. This patch
moves the "__as_link()" member function from "__list_node_base" to "__list_node"
so it cannot be used incorrectly.
Unsafe downcasts now use a non-member function so we don't defer the type-punned
pointer.
llvm-svn: 256727
Summary:
This patch fixes std::list for builtin pointer types in the current ABI version and fixes std::list for all fancy pointer types in the next ABI version. The patch was designed to minimize the amount of code needed to support both ABI configurations. Currently only ~5 lines of code differ.
Reviewers: danalbert, jroelofs, mclow.lists
Subscribers: dexonsmith, awi, cfe-commits
Differential Revision: http://reviews.llvm.org/D12299
llvm-svn: 256652
This patch makes it easier to support running the lit tests for new and
unusual platforms. It will break existing users that set
LIBCXX_TARGET_INFO to anything other than the default. I think this is
fine, because the old LIBCXX_TARGET_INFO wasn't terribly useful.
The old way of supporting the different test platforms was to have
conditional code scattered throughout config.py. New platforms would need
to add conditionals there. Alternatively, the new platform could set
no_default_flags to true, and reconstitue almost the entire compile and
link line, including things that don't vary across platforms.
The new way of supporting new platforms is to create a new target info
class, and have make_target_info return an instance of it. For platforms
supported in-tree, that will be done by modifying make_target_info. For
out-of-tree platforms, users can set LIBCXX_TARGET_INFO at cmake configure
time.
The target info sub-classes can provide fine-grained information back to
config.py. The hooks that will most commonly be provided will be
add_cxx_compile_flags and add_cxx_link_flags. These hooks can provide the
platform specific flags, while letting config.py handle all the invariant
flags.
Target info hooks were added for each area that the existing config.py had
platform specific behavior. config.py is now mostly free of platform
specific conditionals.
This patch was tested on Linux x86_64. I both targeted Linux x86_64, and
an out-of-tree platform with a custom target_info. In both cases I was
able to run libcxx and libcxxabi tests. I do not have access to FreeBSD,
Darwin, or Windows machines that are set up for lit testing.
llvm-svn: 256588
Summary:
This patch allows GCC 4.6 and above to use `noexcept` as opposed to `throw()`.
Is it an ABI safe change to suddenly switch on `noexcept`? I imagine it must be because it's disabled in w/ clang in C++03 but not C++11.
Reviewers: danalbert, jroelofs, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15516
llvm-svn: 255683
This patch goes through and enables C++11 and C++14 features for newer GCC's.
The main changes are:
1. Turn on variable templates. (Uses __cpp_variable_templates)
2. Assert atomic<Tp> is trivially copyable (Uses _GNUC_VER >= 501).
3. Turn on trailing return support for GCC. (Uses _GNUC_VER >= 404)
4. XFAIL void_t test for GCC 5.1 and 5.2. Fixed in GCC 6.
llvm-svn: 255585
No point in pretending that these methods are hidden - they are
actually exported from libc++.so. Extern template declarations make
them part of libc++ ABI.
This patch does not change libc++.so export list (at least on Linux).
llvm-svn: 255177
These are the cases when an out-of-class definition of a method is
marked _LIBCPP_INLINE_VISIBILITY, but the in-class declaration is
not. This will start failing when (or if) we switch to
attribute((internal_linkage)).
llvm-svn: 255166
This is just a build dependency optimization. Running check-libcxx will still build libcxx and function as expected, it just removes libcxx from the all build and install targets.
llvm-svn: 254628
Summary:
Also, there are no exported character type tables from Musl so we have to
Fallback to the standard functions. This reduces the number of libcxx's
test-suite failures down to ~130 for MIPS. Most of the remaining failures
come from the atomics (due to the lack of 8-byte atomic-ops in MIPS32) and
thread tests.
Reviewers: mclow.lists, EricWF, dalias, jroelofs
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D14926
llvm-svn: 253972
The initial buildbot run found a few missing bits in the initial XFAIL list
for the no-exceptions libc++ variant. These discrepancies are as follows:
[1] Following two tests need XFAILs on the no-exceptions library variant.
My local runs had these two disabled for other reasons (unsupported):
- localization/locales/locale/locale.cons/char_pointer.pass.cpp
- numerics/complex.number/complex.ops/complex_divide_complex.pass.cpp
[2] These three does not need XFAILs, they were failing on my local runs for
other reasons:
- depr/depr.c.headers/uchar_h.pass.cpp
- input.output/iostreams.base/ios/basic.ios.members/copyfmt.pass.cpp
- .../category.collate/locale.collate.byname/transform.pass.cpp
(these are failing on my box for the default build as well)
The current patch fixes both the cases above. Additionally, I've run the
following scan to make sure I've covered all the cases:
> grep ' catch \| try \| throw ' -R . | perl -pe 's|(.*?):.*|\1|' | sort | \
uniq > 1.txt
> grep 'libcpp-no-exceptions' -R . | perl -pe 's|(.*?):.*|\1|' | sort | \
uniq > 2.txt
> diff 1.txt 2.txt
This showed up a few extra interesting cases:
[3] These two tests do not use try/catch/throw statements, but they fail at
runtime. Need to be investigated, I've left the XFAILs in.
- std/thread/futures/futures.shared_future/dtor.pass.cpp
- std/thread/futures/futures.unique_future/dtor.pass.cpp
[4] These tests use a macro named TEST_HAS_NO_EXCEPTIONS to conditionally
exclude try/catch/throw statements when running without exceptions. I'm not
entirely sure why this was needed (AFAIK, we didn't have a no-exceptions
library build before). The macro's defintion is quite similar to that of
_LIBCPP_NO_EXCEPTIONS. I will investigate if this can be reused for my test
fixes or if it should be replaced with _LIBCPP_NO_EXCEPTIONS.
- std/experimental/any/*
Change-Id: I9ad1e0edd78f305406eaa0ab148b1ab693f7e26a
llvm-svn: 252870
Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.
This patch adds XFAILS to all those tests that are currently failing
on the new -fno-exceptions library variant. Follow-up patches will
update the tests (progressively) to cope with the new library variant.
Change-Id: I4b801bd8d8e4fe7193df9e55f39f1f393a8ba81a
llvm-svn: 252598
Summary:
This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the
building of libcxx with the Musl C library. The option is necessary as
Musl does not provide any predefined macro in order to test for its
presence, like GLIBC. Most of the changes specify the correct path to
choose through the various #if/#else constructs in the locale code.
Depends on D13407.
Reviewers: mclow.lists, jroelofs, EricWF
Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13673
llvm-svn: 252457
This change moves visibility attributes from out-of-class method
definitions to in-class declaration. This is needed for a switch to
attribute((internal_linkage)) (see http://reviews.llvm.org/D13925)
which can only appear on the first declaration.
This change does not touch istream/ostream/streambuf. They are
handled separately in http://reviews.llvm.org/D14409.
llvm-svn: 252385
Allow deque and deque::iterator instantiation with incomplete element
type. This is an ABI breaking change, and it is only enabled if
LIBCXX_ABI_VERSION >= 2 or LIBCXX_ABI_UNSTABLE=ON.
llvm-svn: 252350
This change caused problems when building code like povray that:
a) uses 'using namespace std;'
b) is built on an environment where the C library provides the "wrong"
(non-const-correct) interface for the str* functions
c) makes an unqualified call to one of those str* functions
A patch is out for review to add a facility to fix this (and to give the
correct signatures for these functions whenever possible, even when the C
library does not do so). This revert is expected to be temporary.
llvm-svn: 251665
This was put in to get libc++ building without libcxxabi. We now have
macros that show that we are building against libcxxabi so use that
instead. This guards against existing but broken cxxabi.h headers on the
system.
llvm-svn: 250507
Summary:
This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever:
1. WIN32 is not defined.
2 UNIX is defined.
3. APPLE is not defined.
While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough.
After committing this patch Linux users will no longer have to use "-lc++abi" explicitly!
Reviewers: mclow.lists, danalbert, compnerd, jroelofs
Subscribers: emaste, rengolin, cbergstrom, cfe-commits
Differential Revision: http://reviews.llvm.org/D13739
llvm-svn: 250469
Marshall Clow