Commit Graph

387 Commits

Author SHA1 Message Date
Louis Dionne f7f5a1f778 [libcxx] Don't depend on availability markup to provide the streams in the dylib
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
2018-12-06 00:24:58 +00:00
Louis Dionne e823b6d7e6 [libcxx] Remove bad_array_length
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
2018-11-29 19:44:57 +00:00
Eric Fiselier 9d25ada420 Revert "Move internal usages of `alignof`/`__alignof` to use `_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
2018-11-28 22:24:19 +00:00
Eric Fiselier 8a486dac25 Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`.
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
2018-11-28 18:16:02 +00:00
Louis Dionne 9a494eacba [libcxx] Remove dynarray
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
2018-11-28 18:02:00 +00:00
Louis Dionne 2804508ffe [libcxx] Remove unused definition of aligned allocation macro on old OS X
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
2018-11-21 21:22:08 +00:00
Louis Dionne 8eb65cb25e [NFC] Reformat availability #defines in __config
Aligning everything makes what we're doing more obvious.

llvm-svn: 347363
2018-11-20 23:18:25 +00:00
Louis Dionne c2b375ad60 [libcxx] Fix threads detection on GNU/Hurd
GNU/Hurd provides standard Posix threads

Reviewed as https://reviews.llvm.org/D54339.
Thanks to Samuel Thibault for the patch.

llvm-svn: 347347
2018-11-20 21:14:05 +00:00
Louis Dionne 8a063df194 [libcxx] Add availability markup for bad_optional_access, bad_variant_access and bad_any_cast
Reviewers: dexonsmith, EricWF

Subscribers: christof, arphaman, libcxx-commits

Differential Revision: https://reviews.llvm.org/D53256

llvm-svn: 347219
2018-11-19 15:37:04 +00:00
Reid Kleckner 60cce5c782 Use C++11 fallthrough attribute syntax when available and add a break
Summary:
This silences the two -Wimplicit-fallthrough warnings clang finds in
ItaniumDemangle.h in libc++abi.

Clang does not have a GNU attribute spelling for this attribute, so this
is necessary.

I will commit the same change to the LLVM demangler soon.

Reviewers: EricWF, ldionne

Subscribers: christof, erik.pilkington, cfe-commits

Differential Revision: https://reviews.llvm.org/D53985

llvm-svn: 345870
2018-11-01 18:24:03 +00:00
Eric Fiselier fe13c13cc2 Make libc++'s versioning namespace customizable
Summary:
This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. 

This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. 

Reviewers: mclow.lists, ldionne

Reviewed By: ldionne

Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits

Differential Revision: https://reviews.llvm.org/D53879

llvm-svn: 345657
2018-10-30 21:44:53 +00:00
Eric Fiselier 2f3e8b3d2e Unify definition of _LIBCPP_BEGIN/END_NAMESPACE_STD
llvm-svn: 345561
2018-10-30 02:02:00 +00:00
Louis Dionne e9d85264ac [libc++] Use exclude_from_explicit_instantiation instead of always_inline
Summary:
This commit adopts the exclude_from_explicit_instantiation attribute discussed
at [1] and reviewed in [2] in libc++ to supplant the use of __always_inline__
for visibility purposes.

This change means that users wanting to link together translation units built
with different versions of libc++'s headers into the same final linked image
MUST define the _LIBCPP_HIDE_FROM_ABI_PER_TU macro to 1 when building those
TUs. Doing otherwise will lead to ODR violations and ABI issues.

[1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html
[2]: https://reviews.llvm.org/D51789

Reviewers: rsmith, EricWF

Subscribers: dexonsmith, libcxx-commits

Differential Revision: https://reviews.llvm.org/D52405

llvm-svn: 345516
2018-10-29 17:30:04 +00:00
Louis Dionne 9b3222f613 [libc++] Make sure we can build libc++ with -fvisibility=hidden
Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.

The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.

Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.

Reviewers: EricWF

Subscribers: mgorny, christof, dexonsmith, libcxx-commits

Differential Revision: https://reviews.llvm.org/D52662

llvm-svn: 345260
2018-10-25 12:13:43 +00:00
Louis Dionne 4084df0040 [libcxx] Avoid repeating the definition of std:: namespaces
This reduces code duplication a tiny bit.

llvm-svn: 344642
2018-10-16 20:02:59 +00:00
Louis Dionne 7833b88ad8 [libcxx] Remove _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY
That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many
weeks now, so we're actually replacing uses of it for uses of
_LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly.

This should not change or break anything since the two macros are
100% equivalent, unless somebody is (incorrectly!) relying on
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined.

llvm-svn: 344641
2018-10-16 19:26:23 +00:00
Marshall Clow 5b08c1742a Recommit <chrono> changes with a couple xtra tests marked to fail on apple's clang. Reviewed as D51762
llvm-svn: 344627
2018-10-16 17:27:54 +00:00
Artem Dergachev a9bc0face5 Revert r344529 "Implement the first part of the calendar support for C++20"
Revert r344535 "Wrap up the new chrono literals in an #ifdef..."
Revert r344546 "Mark a couple of test cases as 'C++17-only'..."

Some of the buildbot failures were masked by another error,
and this one was probably missed.

llvm-svn: 344580
2018-10-16 02:40:42 +00:00
Marshall Clow 323e01d46f Wrap up the new chrono literals in an #ifdef so that old versions of clang don't complain. I'm looking at you, clang 5.0.1
llvm-svn: 344535
2018-10-15 17:33:20 +00:00
Eric Fiselier 42f9868cd8 Distinguish between library and language support for aligned allocation.
There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.

There are times where libc++ needs to distinguish between the two.

This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.

Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.

llvm-svn: 344207
2018-10-11 00:17:24 +00:00
Louis Dionne f9a52903ef [libc++] Remove Fuchsia-specific knowledge to pick the ABI version
Summary:
The ABI version used by libc++ is a configuration option just like any other
configuration option. It is a knob that can be used by vendors to customize
the libc++ that they ship. As such, we should not be hardcoding vendor-specific
configuration choices in libc++.

When building libc++ for Fuchsia, Fuchsia's build scripts should simply define
the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION
macro being defined in the __config header that is generated when libc++ is
built and installed, which is the correct way to customize libc++'s behavior
for specific vendors.

Reviewers: phosek, EricWF

Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits

Differential Revision: https://reviews.llvm.org/D52397

llvm-svn: 343079
2018-09-26 08:24:51 +00:00
Louis Dionne ea5cd3b476 [libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:

in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()

in C++14:
- random_shuffle()

in C++17:
- unary_negate, binary_negate, not1(), not2()

<rdar://problem/18168350>

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D48912

llvm-svn: 342843
2018-09-23 18:35:00 +00:00
Roman Lebedev c65d39a464 [libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow pre-C++2a [[nodiscard]]
Summary:
The `[[nodiscard]]` attribute is intended to help users find bugs where
function return values are ignored when they shouldn't be. After C++17 the
C++ standard has started to declared such library functions as `[[nodiscard]]`.
However, this application is limited and applies only to dialects after C++17.
Users who want help diagnosing misuses of STL functions may desire a more
liberal application of `[[nodiscard]]`.

For this reason libc++ provides an extension that does just that! The
extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended
applications of `[[nodiscard]]` takes two forms:

1. Backporting `[[nodiscard]]` to entities declared as such by the
   standard in newer dialects, but not in the present one.

2. Extended applications of `[[nodiscard]]`, at the libraries discretion,
   applied to entities never declared as such by the standard.

Users may also opt-out of additional applications `[[nodiscard]]` using
additional macros.

Applications of the first form, which backport `[[nodiscard]]` from a newer
dialect may be disabled using macros specific to the dialect it was added. For
example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`.

Applications of the second form, which are pure extensions, may be disabled
by defining `_LIBCPP_DISABLE_NODISCARD_EXT`.

This patch was originally written by me (Roman Lebedev),
then but then reworked by Eric Fiselier.

Reviewers: mclow.lists, thakis, EricWF

Reviewed By: thakis, EricWF

Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof

Differential Revision: https://reviews.llvm.org/D45179

llvm-svn: 342808
2018-09-22 17:54:48 +00:00
Louis Dionne 61cd687009 [libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.

In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.

Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.

Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D50652

llvm-svn: 339874
2018-08-16 12:44:28 +00:00
Marshall Clow 171c77b7da Selectively import timespec_get into namespace std, since some C libraries don't have it. Reviewed as https://reviews.llvm.org/D50799
llvm-svn: 339816
2018-08-15 21:19:08 +00:00
Louis Dionne 894ffdd82f [libc++] Detect C11 features on non-Clang compilers
Summary:
The macros were inside `#if defined(_LIBCPP_COMPILER_CLANG)`, which means
we would never detect C11 features on non-Clang compilers. According to
Marshall Clow, this is not the intended behavior.

Reviewers: mclow.lists, EricWF

Subscribers: krytarowski, christof, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D50748

llvm-svn: 339741
2018-08-15 00:16:41 +00:00
Louis Dionne 53ac1776f3 [libc++] Enable aligned allocation based on feature test macro, irrespective of standard
Summary:
The current code enables aligned allocation functions when compiling in C++17
and later. This is a problem because aligned allocation functions might not
be supported on the target platform, which leads to an error at link time.

Since r338934, Clang knows not to define __cpp_aligned_new when it's not
available on the target platform -- this commit takes advantage of that to
only use aligned allocation functions when they are available.

Reviewers: vsapsai, EricWF

Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists

Differential Revision: https://reviews.llvm.org/D50344

llvm-svn: 339431
2018-08-10 13:24:56 +00:00
Louis Dionne ba71bd7c55 [libc++] Add the _LIBCPP_HIDE_FROM_ABI_AFTER_V1 macro
Summary:
This macro allows hiding symbols from the ABI when the library is built
with an ABI version after ABI v1, which is currently the only stable ABI.
This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be
`_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only
exported by the library for historical reasons are not exported anymore
in the unstable ABI.

Because of that, this commit is an ABI break for ABI v2. This ABI version
is not stable, however, so this should not be a problem.

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D49914

llvm-svn: 339012
2018-08-06 14:11:50 +00:00
Hans Wennborg 25977548aa Update version to 8.0.0svn: cmake, includes files and docs
llvm-svn: 338555
2018-08-01 13:54:28 +00:00
Louis Dionne 306b73e35b [libc++] Fix GCC 7.2.0 macro redefinition warning
The warning happens when LIBCXX_ENABLE_EXCEPTIONS cmake option is not set,
and it fires every time __config is included, 33 in total.

Patch by Jason Lovett
Reviewed as https://reviews.llvm.org/D49997

llvm-svn: 338531
2018-08-01 13:13:14 +00:00
Tim Shen 38cd7de5ac Re-apply "[libcxx] implement <simd> ABI for Clang/GCC vector extension, constructors, copy_from and copy_to."
...with proper guarding #ifdefs for unsupported C++11.

llvm-svn: 338318
2018-07-30 22:27:38 +00:00
Tim Shen 6f33ea4ef6 Revert "[libcxx] implement <simd> ABI for Clang/GCC vector extension, constructors, copy_from and copy_to."
This reverts commit r338309.

llvm-svn: 338316
2018-07-30 22:21:22 +00:00
Tim Shen 47ad09b339 [libcxx] implement <simd> ABI for Clang/GCC vector extension, constructors, copy_from and copy_to.
Summary:
This patch adds a new macro _LIBCPP_HAS_NO_VECTOR_EXTENSION for detecting
whether a vector extension (\_\_attribute\_\_((vector_size(num_bytes)))) is
available.

On the top of that, this patch implements the following API:
* all constructors
* operator[]
* copy_from
* copy_to

It also defines simd_abi::native to use vector extension, if available.
In GCC and Clang, certain values with vector extension are passed by registers,
instead of memory.

Based on D41148.

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits, MaskRay, lichray, sanjoy

Differential Revision: https://reviews.llvm.org/D41376

llvm-svn: 338309
2018-07-30 21:23:13 +00:00
Louis Dionne cb3eb30636 [libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITY
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.

It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:

    http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html

This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.

In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html

Reviewers: EricWF, dexonsmith, mclow.lists

Subscribers: christof, dexonsmith, llvm-commits, mclow.lists

Differential Revision: https://reviews.llvm.org/D49240

llvm-svn: 338122
2018-07-27 12:46:03 +00:00
Eric Fiselier 8e4a1690bf Move Filesystem namespace definition out of a clang specific ifdef block.
llvm-svn: 338103
2018-07-27 06:12:46 +00:00
Eric Fiselier 998a5c8831 Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.

Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).

The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).

Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.

In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.

llvm-svn: 338093
2018-07-27 03:07:09 +00:00
Alexander Richardson 2a6a3fc4a3 Stop wrapping __has_include in another macro
Summary:
This is not guaranteed to work since the characters after '__has_include('
have special lexing rules that can't possibly be applied when
__has_include is generated by a macro. It also breaks the crash reproducers
generated by -frewrite-includes (see https://llvm.org/pr37990).

Reviewers: EricWF, rsmith, mclow.lists
Reviewed By: mclow.lists
Differential Revision: https://reviews.llvm.org/D49067

llvm-svn: 337824
2018-07-24 12:40:56 +00:00
Marshall Clow 75c4f5552e wrap _LIBCPP_HAS_NO_CXX14_CONSTEXPR in defined(...)
llvm-svn: 337028
2018-07-13 17:31:36 +00:00
Marshall Clow 2d1d690863 Shot in the dark to fix gcc 4.9 / c++11 build
llvm-svn: 337027
2018-07-13 17:24:59 +00:00
Marshall Clow 9cad502555 Make internal class __wrap_iter constexpr when not using libc++'s debugging mode. Introduce a new macro _LIBCPP_CONSTEXPR_IF_NODEBUG to mark this.
llvm-svn: 337019
2018-07-13 16:35:26 +00:00
Louis Dionne dc7200b486 [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, erikvanderpoel

Differential Revision: https://reviews.llvm.org/D48892

llvm-svn: 336866
2018-07-11 23:14:33 +00:00
Louis Dionne 195a499d63 Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
   _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
   dylib and the check-cxx-abilist failing.

2. The LLDB tests started failing because they undefine
   `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
   fix the tests before we can go forward with this change.

llvm-svn: 336382
2018-07-05 18:41:50 +00:00
Louis Dionne 4a8f3f9948 [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Reviewers: EricWF

Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists

Differential Revision: https://reviews.llvm.org/D48892

llvm-svn: 336369
2018-07-05 16:49:38 +00:00
JF Bastien f764dbd023 Revert "Add nonnull; use it for atomics"
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.

Marshall asked to revert:

Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.

llvm-svn: 333351
2018-05-26 19:44:45 +00:00
JF Bastien 1be7517aa9 Add nonnull; use it for atomics
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:

  - A warning should be generated if the argument is null
  - It is undefined behavior if the argument is null (because a dereference will segfault)

This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625

The attributes are documented:

  - https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
  - https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes

I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.

In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.

<rdar://problem/18473124>

Reviewers: arphaman, EricWF

Subscribers: aheejin, christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D47225

llvm-svn: 333325
2018-05-25 23:43:53 +00:00
Reid Kleckner 6a2a5e0abb Don't do aligned allocations on MSVCRT before 19.12 (update 15.3)
Reviewers: EricWF, pcc

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D45836

llvm-svn: 330372
2018-04-19 22:12:10 +00:00
Reid Kleckner 317a6ddea7 Remove impossible _MSC_VER check
Summary:
It is immediately preceded by this check:
  #if _MSC_VER < 1900
  #error "MSVC versions prior to Visual Studio 2015 are not supported"
  #endif

Reviewers: EricWF

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D45829

llvm-svn: 330360
2018-04-19 19:40:12 +00:00
Petr Hosek 2b3846306d [libcxx] Set ABI version 2 as default for Fuchsia
This avoids the need for a custom generated config file which is desired
because the custom config files differs per-target which means we cannot
reuse headers across different targets.

Differential Revision: https://reviews.llvm.org/D45304

llvm-svn: 329770
2018-04-11 01:06:28 +00:00
Eric Fiselier 0913ca1978 Implement P0768r1: Library support for the Spaceship Operator.
this patch adds the <compare> header and implements all of it
except for [comp.alg].

As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.

llvm-svn: 329460
2018-04-06 21:37:23 +00:00
Eric Fiselier f2918d1c24 Fix PR22634 - std::allocator doesn't respect over-aligned types.
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.

__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).

When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.

This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.

llvm-svn: 328180
2018-03-22 04:42:56 +00:00