This was discussed on Discord with the consensus that we should rename the macros.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D131498
This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
The ostream operator<< is currently broken for std::complex with
specified field widths.
This patch a partial revert of c3478eff7a (reviewed as D71214),
restoring the correct behavior.
Differential Revision: https://reviews.llvm.org/D78816
Instead of including <ios> for ios_base::failbit, simply get failbit
member of the template argument. Print directly to a stream instead
of using intermediate ostringstream.
Parsing time: 874ms -> 164ms (-81%)
Thanks to Nikita Kniazev for the patch!
Differential Revision: https://reviews.llvm.org/D71214
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
llvm-svn: 307357
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).
This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.
llvm-svn: 291035
The libc-provided isnan/isinf/isfinite macro implementations are specifically
designed to function correctly, even in the presence of -ffast-math (or, more
specifically, -ffinite-math-only). As such, on most implementation, these
either always turn into external function calls (e.g. glibc) or are
specifically function calls when FINITE_MATH_ONLY is defined (e.g. Darwin).
Our implementation of complex arithmetic makes heavy use of isnan/isinf/isfinite
to deal with corner cases involving non-finite quantities. This was problematic
in two respects:
1. On systems where these are always function calls (e.g. Linux/glibc), there was a
performance penalty
2. When compiling with -ffast-math, there was a significant performance
penalty (in fact, on Darwin and systems with similar implementations, the code
may in fact be slower than not using -ffast-math, because the inline
definitions provided by libc become unavailable to prevent the checks from
being optimized out).
Eliding these inf/nan checks in -ffast-math mode is consistent with what
happens with libstdc++, and in my experience, what users expect. This is
critical to getting high-performance code when using complex<T>. This change
replaces uses of those functions on basic floating-point types with calls to
__builtin_isnan/isinf/isfinite, which Clang will always expand inline. When
using -ffast-math (or -ffinite-math-only), the optimizer will remove the checks
as expected.
Differential Revision: https://reviews.llvm.org/D18639
llvm-svn: 283051
The functions arg, conj, imag, norm, proj, and real have additional overloads
for arguments of integral or floating point types. However these overloads should
not allow conversions to the integral/floating point types, only exact matches.
This patch constrains these functions so they no longer allow conversions.
llvm-svn: 276067
