Summary:
I can't think of a reason for shipping this empty header. If there is
a reason to do so, then hopefully this review can uncover it.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59137
llvm-svn: 355829
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:
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
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
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
Use strtof and strtod for floats and doubles respectively instead of
always using strtold. The other parts of the change are already implemented
in libc++.
This patch also has a drive by fix to wbuffer_convert::underflow() which
prevents it from calling memmove(buff, null, 0).
llvm-svn: 273106
The various _l locale extension functions originate from very
different places. Some come from POSIX, some are BSD extensions,
and some are shared BSD and GLIBC extensions. This patch tries to
group the local extension reimplementations by source. This should
make it easier to make libcxx work with POSIX compliant C libraries
that lack these extensions.
The fallback locale functions are also useful on their own for other
lightweight platforms. Putting these fallback implementations in
support/xlocale should enable code sharing.
I have no access to a newlib system or an android system to build
and test with. I _do_ have access to a system without any of the _l
locale extensions though, and I was able to ensure that the new
__posix_l_fallback.h and __strtonum_fallback.h didn't have any massive
problems.
http://reviews.llvm.org/D17416
llvm-svn: 270213
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
Louis Dionne