Commit Graph

146 Commits

Author SHA1 Message Date
Louis Dionne eb8650a757 [runtimes][NFC] Remove filenames at the top of the license notice
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.
2021-11-17 16:30:52 -05:00
MarcoFalke faa019c0e3
[libc++] Fix segmentation fault in __do_put_integral
6 chars are not sufficient to represent all formats for 64 bit integers.

This was accidentally introduced in commit b889cbf366 (https://reviews.llvm.org/D112830).

This causes failures in downstream projects, for example:

* https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40817
* https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40841

Differential Revision: https://reviews.llvm.org/D113600
2021-11-10 21:26:05 +01:00
Louis Dionne a4ba780510 [libc++] Enable -Wformat-nonliteral when building libc++
Using user-provided data as a format string is a well known source of
security vulnerabilities. For this reason, it is a good idea to compile
our code with -Wformat-nonliteral, which basically warns if a non-constant
string is used as a format specifier. This is the compiler’s best signal
that a format string call may be insecure.

I audited the code after adding the warning and made sure that the few
places where we used a non-literal string as a format string were not
potential security issues. I either disabled the warning locally for
those instances or fixed the warning by using a literal. The idea is
that after we add the warning to the build, any new use of a non-literal
string in a format string will trigger a diagnostic, and we can either
get rid of it or disable the warning locally, which is a way of
acknowledging that it has been audited.

I also looked into enabling it in the test suite, which would perhaps
allow finding additional instances of it in our headers, however that
is not possible at the moment because Clang doesn't support putting
__attribute__((__format__(...))) on variadic templates, which would
be needed.

rdar://84571685

Differential Revision: https://reviews.llvm.org/D112927
2021-11-09 13:17:45 -05:00
Daniel McIntosh 41481b7db5 [libcxx][NFC] tidy up money_get::__do_get's sign parsing
Same logic, but much easier to read this way

Reviewed By: ldionne, #libc, Mordante

Differential Revision: https://reviews.llvm.org/D112958
2021-11-04 17:55:28 -04:00
Louis Dionne b889cbf366 [libc++] Refactor num_put::do_put to reduce duplication
I was going to make a change in that area of the code and I noticed that
we basically duplicated the same code 5 times to handle integral types
and floating point types. This commit simply pulls the duplication into
a function.

Differential Revision: https://reviews.llvm.org/D112830
2021-11-01 10:05:10 -04:00
Louis Dionne f4c1258d56 [libc++] Add an option to disable wide character support in libc++
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

Differential Revision: https://reviews.llvm.org/D111265
2021-10-12 06:08:23 -04:00
Louis Dionne 87dd51983c [libc++] Remove support for CloudABI, which has been abandoned
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI
project has been abandoned. This patch removes a bunch of CloudABI specific
logic that had been added to support that platform.

Note that some knobs like LIBCXX_ENABLE_STDIN and LIBCXX_ENABLE_STDOUT
coud be useful in their own right, however those are currently broken.
If we want to re-add such knobs in the future, we can do it like we've
done it for localization & friends so that we can officially support
that configuration.

Differential Revision: https://reviews.llvm.org/D108637
2021-08-24 14:11:32 -04:00
Jason Liu 363a8a0598 [libc++] money_get::do_get() set failbit and eofbit if iterator begin equals end
Summary:
Currently, if we pass in the same iterator for begin and end,
the long double version of do_get would throw a runtime error.

However, according to standard (https://eel.is/c++draft/locale.money.get#virtuals-1),
we should set the failbit and eofbit when no more characters are available.

Differential Revision: https://reviews.llvm.org/D100510
2021-07-28 22:23:09 -04:00
Daniel McIntosh ee2a92c29d [libcxx] Remove VLA from libcxx locale header
The buffer size (`__nbuf`) in `num_put::do_put` is currently not an
integral/core constant expression. As a result, `__nar` is a Variable Length
Array (VLA). VLAs are a GNU extension and not part of the base C++ standard, so
unless there is good reason to do so they probably shouldn't be used in any of
the standard library headers. The call to `__iob.flags()` is the only thing
keeping `__nbuf` from being a compile time constant, so the solution here is to
simply err on the side of caution and always allocate a buffer large enough to
fit the base prefix.

Note that, while the base prefix for hex (`0x`) is slightly longer than the
base prefix for octal (`0`), this isn't a concern. The difference in the space
needed for the value portion of the string is enough to make up for this.
(Unless we're working with small, oddly sized types such as a hypothetical
`uint9_t`, the space needed for the value portion in octal is at least 1 more
than the space needed for the value portion in hex).

This PR also adds `constexpr` to `__nbuf` to enforce compile time const-ness
going forward.

Reviewed By: Mordante, #libc, Quuxplusone, ldionne

Differential Revision: https://reviews.llvm.org/D103558
2021-06-08 13:59:34 -04:00
Daniel McIntosh 06e047227d [libcxx][NFC] Tidy up calculation of __nbuf in num_put::do_put, and add comments
In 07ef8e6796 and 3ed9f6ebde, `__nbuf` started to diverge from the amount
of space that was actually needed for the buffer. For 32-bit longs for example,
we allocate a buffer that is one larger than needed. Moreover, it is no longer
clear exactly where the extra +1 or +2 comes from - they're just numbers pulled
from thin air. This PR cleans up how `__nbuf` is calculated, and adds comments
to further clarify where each part comes from.

Specifically, it corrects the underestimation of the max size buffer needed
that the above two commits had to compensate for. The root cause looks to be
the use of signed type parameters to numeric_limits<>::digits. Since digits
only counts non-sign bits, the calculation was acting as though (for a signed
64-bit type) the longest value we would print was 2^63 in octal. However,
printing in octal treats values as unsigned, so it is actually 2^64. Thus,
using unsigned types and changing the final +2 to a +1 is probably a better
option.

Reviewed By: #libc, ldionne, Mordante

Differential Revision: https://reviews.llvm.org/D103339
2021-06-02 11:46:17 -04:00
Arthur O'Dwyer bfbd73f87d [libc++] Alphabetize and include-what-you-use. NFCI.
Differential Revision: https://reviews.llvm.org/D102781
2021-05-29 19:54:48 -04:00
Arthur O'Dwyer b98b6d99c5 [libc++] Eliminate macro _LIBCPP_UNUSED_VAR. NFCI.
Reviewed as part of https://reviews.llvm.org/D100737
2021-04-22 12:02:22 -04:00
Louis Dionne 4cd6ca102a [libc++] NFC: Normalize `#endif //` comment indentation 2021-04-20 12:03:32 -04:00
Mara Sophie Grosch 8deaa4a147 [libc++] Move checks for newlib to actually work
The checks did not work in __config, since no header defining
`_NEWLIB_VERSION` was included before. This patch moves the two
checks for newlib to the headers that actually need it - and after
they already include relevant headers.

Differential Revision: https://reviews.llvm.org/D79888
2021-04-12 14:20:36 -04:00
Brad Smith 1be2524b7d [libcxx] Check return value for asprintf()
local __libcpp_asprintf_l() -> libc asprintf() was inspecting the pointer (with
indeterminate value) for failure, rather than the return value of -1.

Reviewed By: ldionne

Differential Revision: https://reviews.llvm.org/D94564
2021-01-21 19:43:11 -05:00
Louis Dionne 68dba7eae1 [libc++] Unbreak the debug mode
When the Debug mode is enabled, we disable extern declarations because we
don't want to use the functions compiled in the library, which might not
have had the debug mode enabled when built. However, some extern declarations
need to be kept, because code correctness depends on it.

31e820378b removed those declarations, which had the unintended
consequence of breaking the debug build. This commit fixes that by
re-introducing a separate macro for the required extern declarations,
and adds a comment so that we don't fall into that trap in the future.

Differential Revision: https://reviews.llvm.org/D94718
2021-01-19 14:15:31 -05:00
Marek Kurdej a11f8b1ad6 [libc++] [P0935] [C++20] Eradicating unnecessarily explicit default constructors from the standard library.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0935r0.html

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D91292
2021-01-19 08:22:06 +01:00
Arthur O'Dwyer 3696227c10 [libc++] ADL-proof by adding _VSTD:: qualifications to memmove etc.
Generally these calls aren't vulnerable to ADL because they involve only
primitive types. The ones in <list> and <vector> drag in namespace std
but that's OK; the ones in <fstream> and <strstream> are vulnerable
iff `CharT` is an enum type, which seems far-fetched.
But absolutely zero of them *need* ADL to happen; so in my opinion
they should all be consistently qualified, just like calls to any
other (non-user-customizable) functions in namespace std.

Also: Include <cstring> and <cwchar> in <__string>.
We seemed to be getting lucky that <memory> included <iterator>
included <iosfwd> included <wchar.h>. That gave us the
global-namespace `wmemmove`, but not `_VSTD::wmemmove`.
This is now fixed.

I didn't touch these headers:
<ext/__hash> uses strlen, safely
<support/ibm/locale_mgmt_aix.h> uses memcpy, safely
<string.h> uses memchr and strchr, safely
<wchar.h> uses wcschr, safely
<__bsd_locale_fallbacks.h> uses wcsnrtombs, safely

Differential Revision: https://reviews.llvm.org/D93061
2020-12-10 22:03:12 -05:00
Arthur O'Dwyer 1968804ac7 [libc++] Add _VSTD:: qualifications to ADL-proof <algorithm>.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/

Differential Revision: https://reviews.llvm.org/D92776
2020-12-08 17:05:38 -05:00
Bruce Mitchener 527a7fdfbd [libc++] Replace several uses of 0 by nullptr
Differential Revision: https://reviews.llvm.org/D43159
2020-11-27 10:00:21 -05:00
Louis Dionne 8da0df3d6d [libc++] Remove unused includes of Availability.h
Since ebaf1d5e2b, the macros defined in <Availability.h> are not used
anymore.
2020-10-07 18:03:40 -04:00
Louis Dionne 31e820378b [libc++] NFCI: Simplify macro definitions for the debug mode
The debug mode always had three possibilities:
- _LIBCPP_DEBUG is undefined => no assertions
- _LIBCPP_DEBUG == 0         => some assertions
- _LIBCPP_DEBUG == 1         => some assertions + iterator checks

This was documented that way, however the code did not make this clear
at all. The discrepancy between _LIBCPP_DEBUG and _LIBCPP_DEBUG_LEVEL
was especially confusing. I reworked how the various macros are defined
without changing anything else to make the code clearer.
2020-10-02 15:11:23 -04:00
Louis Dionne 1a92de0064 [libc++] NFCI: Remove _LIBCPP_EXTERN_TEMPLATE2
This seems to have been added a long time ago as a temporary help
for debugging some <regex> issue, but it's really the same as
_LIBCPP_EXTERN_TEMPLATE.
2020-10-02 14:31:43 -04:00
Louis Dionne a2a1ec27d0 [NFC][libcxx] Remove trailing whitespace
It's incredibly annoying when trying to create diffs

llvm-svn: 361981
2019-05-29 16:01:36 +00:00
Louis Dionne ebaf1d5e2b [libc++] Unconditionally enable the __pad_and_output optimization
This used to be guarded on whether the deployment target was greater
than macosx10.8, however testing against the dylibs for 10.8 and earlier
with the function enabled works too. The revision that introduced
__pad_and_output is r164241 and it does not mention a reason for the
guard.

llvm-svn: 358677
2019-04-18 15:19:35 +00:00
Marshall Clow 2e719bc428 add a test and a couple minor bug fixes for the implicit-signed-integer-truncation sanitizer. This is PR#40566
llvm-svn: 352926
2019-02-01 21:59:27 +00:00
Chandler Carruth 57b08b0944 Update more file headers across all of the LLVM projects in the monorepo
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
2019-01-19 10:56:40 +00:00
Petr Hosek 2fefe153dd [libcxx] Mark do_open, do_get and do_close parameters unused when catopen is missing
When catopen is missing, do_open, do_get and do_close end up being
no-op, and as such their parameters will be unused which triggers a
warning/error when building with -Wunused-parameter.

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

llvm-svn: 351027
2019-01-13 22:15:37 +00:00
Marshall Clow 7dad0bd68b Second part of P0482 - char8_t. Reviewed as https://reviews.llvm.org/D55308
llvm-svn: 348828
2018-12-11 04:35:44 +00:00
Louis Dionne 835140a427 [libcxx] Make sure we can build with -fvisibility=hidden on Linux
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
2018-11-21 16:24:46 +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 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
Eric Fiselier bc3a21f823 Fix PR36914 - num_get::get(unsigned) incorrectly handles negative numbers.
This patch corrects num_get for unsigned types to support strings
with a leading `-` character. According to the standard the
number should be parsed as an unsigned integer and then
negated.

llvm-svn: 328751
2018-03-29 01:18:53 +00:00
Marshall Clow d90758e2ef Make pbump (internally) handle sizes bigger than MAX_INT. Fixes PR#33725 - thanks to Jonathan Wakely for the report
llvm-svn: 313031
2017-09-12 15:00:43 +00:00
Aditya Kumar 38bc3df8a3 [locale] Avoid copy of __atoms when char_type is char
The function num_get<_CharT>::stage2_int_prep makes unnecessary copy of src
into atoms when char_type is char. This can be avoided by creating
a switch on type and just returning __src when char_type is char.

Added the test case to demonstrate performance improvement.
In order to avoid ABI incompatibilities, the changes are guarded
with a macro _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET

Differential Revision: https://reviews.llvm.org/D30268
Reviewed by: EricWF

llvm-svn: 305427
2017-06-14 23:17:45 +00:00
Marshall Clow 8b086e3878 Add some const_casts in places where we were implicitly casting away constness. No functional change, but now they're explicit
llvm-svn: 305410
2017-06-14 20:00:36 +00:00
Eric Fiselier 1ec026252b Fix Libc++ build with MinGW64
Summary: This patch corrects the build errors I encountered when building on MinGW64.

Reviewers: mati865, rnk, compnerd, smeenai, bcraig

Reviewed By: mati865, smeenai

Subscribers: martell, chapuni, cfe-commits

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

llvm-svn: 304360
2017-05-31 22:14:05 +00:00
Eric Fiselier a016efb1dc [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on Windows
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro`  to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.

Reviewers: mclow.lists, bcraig, compnerd, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits, krytarowski

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

llvm-svn: 304357
2017-05-31 22:07:49 +00:00
Eric Fiselier b4ddab26bc Refactor <locale> RAII guards to aid upcoming Windows locale changes.
Previously <locale> used std::unique_ptr<remove_ptr<locale_t>, locale-mgmt-function>
as a scope guard for (A) creating new locales, and (B) setting the thread specific locale
in RAII safe manner.

However using unique_ptr has some problems, first it requires that locale_t is a pointer
type, which may not be the case (Windows will need a non-pointer locale_t type that emulates _locale_t).

The second problem is that users of the guards had to supply the locale management function to the custom
deleter at every call site. However these locale management functions don't exist natively Windows, making
a good Windows implementation of locale more difficult.

This patch creates distinct and simply RAII guards that replace unique_ptr. These guards handle calling
the correct locale management function so that callers don't have too. This simplification will
aid in upcoming Windows fixes.

llvm-svn: 302474
2017-05-08 22:02:43 +00:00
Eric Fiselier c04013f5f4 Fix DLL import for __time_get_c_storage member functions.
llvm-svn: 302390
2017-05-08 00:29:32 +00:00
Dimitry Andric 52844c83d0 Ensure showbase does not overflow do_put buffers
Summary:
In https://bugs.freebsd.org/207918, Daniel McRobb describes how using
std::showbase with ostreams can cause truncation of unsigned long long
when output format is octal.  In fact, this can even happen with
unsigned int and unsigned long.

To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on.  Also add a test case.

Reviewers: EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: cfe-commits, emaste

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

llvm-svn: 302362
2017-05-06 20:58:50 +00:00
Eric Fiselier 807790a09b Fix new warnings emitted by GCC 7
llvm-svn: 302280
2017-05-05 20:32:26 +00:00
Eric Fiselier 046492b932 Cleanup usages of _LIBCPP_HAS_NO_<c++11-feature> in <bitset>, <ios>, <locale>, and <iterator>
llvm-svn: 300648
2017-04-19 01:34:08 +00:00
Shoaib Meenai cf38eb99de [libc++] Explicitly mark specializations as dllexport
Method specializations don't get exported even if there's an exported
extern template instantiation on Windows. Explicitly mark the methods
for export. They're already exported on Linux and Darwin, so there's no
ABI change on those platforms.

llvm-svn: 299348
2017-04-03 04:04:24 +00:00
Shoaib Meenai bad28c44eb [libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export members
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.

An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.

Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.

It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.

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

llvm-svn: 296731
2017-03-02 03:02:50 +00:00
Shoaib Meenai a528e74735 [libc++] Mark some std::num_get method templates inline
D29157 will make explicit template instantiations expand to default
visibility, at which point these method templates will need to be
explicitly marked hidden visibility to avoid leaking into other DSOs.
Unfortunately, because of clang PR32114, they must be marked inline (in
conjunction with `-fvisibility-inlines-hidden`) to actually hide them,
since clang doesn't respect the hidden visibility annotation.

Since this involves an ABI change, mark these methods inline in a
separate change, so that the ABI changes can be reviewed separately and
verified to be safe.

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

llvm-svn: 296729
2017-03-02 02:51:27 +00:00
Eric Fiselier e2f2d1edef [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS
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
2017-01-04 23:56:00 +00:00
Shoaib Meenai fe1aacd014 [libc++] Make __num_get_float hidden
It's an internal function and shouldn't be exported. It's also a source
of discrepancy in the published ABI list; these symbols aren't exported
for me on CentOS 7 or Ubuntu 16.04, leading to spurious check-cxx-abilist
failures.

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

llvm-svn: 290503
2016-12-24 18:05:32 +00:00