[libc++] __uglify `[[clang::noescape]]` (#113280)

Identifiers `clang` and `noescape` are not reserved by the C++ standard,
so perhaps we need to use the equivalent reserved forms.

Also changes t

[libc++] __uglify `[[clang::noescape]]` (#113280)

Identifiers `clang` and `noescape` are not reserved by the C++ standard,
so perhaps we need to use the equivalent reserved forms.

Also changes the occurrences of that attribute to a macro, following the
convention for `[[_Clang::__lifetimebound__]]`.

Addresses
https://github.com/llvm/llvm-project/pull/91651#discussion_r1807852646.

show more ...

[libcxx][libc] Hand in Hand PoC with from_chars (#91651)

Implements std::from_chars for float and double.

The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc

[libcxx][libc] Hand in Hand PoC with from_chars (#91651)

Implements std::from_chars for float and double.

The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)

https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701

show more ...

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmar

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all

show more ...

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging t

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging them.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, krytarowski, smeenai

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

show more ...

[libc++] Extend check for non-ASCII characters to src/, test/ and benchmarks/

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

[libc++] Improve charconv base10 algorithm.

This change is a preparation to add the 128-bit integral output.

Before
```
--------------------------------------------------------------
Benchmark

[libc++] Improve charconv base10 algorithm.

This change is a preparation to add the 128-bit integral output.

Before
```
--------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------
BM_to_chars_good/2 20.1 ns 20.1 ns 35045000
BM_to_chars_good/3 117 ns 117 ns 5916000
BM_to_chars_good/4 83.7 ns 83.7 ns 8401000
BM_to_chars_good/5 70.6 ns 70.6 ns 9915000
BM_to_chars_good/6 59.9 ns 59.9 ns 11678000
BM_to_chars_good/7 53.9 ns 53.8 ns 12995000
BM_to_chars_good/8 19.0 ns 19.0 ns 37110000
BM_to_chars_good/9 45.9 ns 45.8 ns 15278000
BM_to_chars_good/10 9.24 ns 9.24 ns 75343000
BM_to_chars_good/11 42.6 ns 42.6 ns 16449000
BM_to_chars_good/12 38.8 ns 38.8 ns 18101000
BM_to_chars_good/13 38.8 ns 38.8 ns 17999000
BM_to_chars_good/14 37.7 ns 37.6 ns 18571000
BM_to_chars_good/15 35.8 ns 35.8 ns 19660000
BM_to_chars_good/16 15.4 ns 15.4 ns 46129000
BM_to_chars_good/17 32.3 ns 32.3 ns 21763000
BM_to_chars_good/18 32.8 ns 32.8 ns 21396000
BM_to_chars_good/19 33.4 ns 33.4 ns 21078000
BM_to_chars_good/20 33.3 ns 33.3 ns 21020000
BM_to_chars_good/21 32.3 ns 32.3 ns 21807000
BM_to_chars_good/22 31.6 ns 31.6 ns 22057000
BM_to_chars_good/23 30.7 ns 30.7 ns 22938000
BM_to_chars_good/24 28.3 ns 28.3 ns 24659000
BM_to_chars_good/25 28.2 ns 28.2 ns 24790000
BM_to_chars_good/26 28.4 ns 28.4 ns 24410000
BM_to_chars_good/27 28.7 ns 28.7 ns 24423000
BM_to_chars_good/28 28.9 ns 28.9 ns 24139000
BM_to_chars_good/29 28.9 ns 28.9 ns 24347000
BM_to_chars_good/30 29.2 ns 29.2 ns 24141000
BM_to_chars_good/31 29.6 ns 29.6 ns 23699000
BM_to_chars_good/32 29.5 ns 29.5 ns 23933000
BM_to_chars_good/33 28.9 ns 28.9 ns 24042000
BM_to_chars_good/34 28.7 ns 28.7 ns 24361000
BM_to_chars_good/35 28.3 ns 28.3 ns 24703000
BM_to_chars_good/36 28.1 ns 28.1 ns 24924000
BM_to_chars_bad/2 6.16 ns 6.15 ns 114101000
BM_to_chars_bad/3 14.5 ns 14.5 ns 48244000
BM_to_chars_bad/4 16.9 ns 16.9 ns 41974000
BM_to_chars_bad/5 12.5 ns 12.5 ns 56080000
BM_to_chars_bad/6 10.9 ns 10.9 ns 64036000
BM_to_chars_bad/7 14.5 ns 14.5 ns 47294000
BM_to_chars_bad/8 6.36 ns 6.35 ns 110430000
BM_to_chars_bad/9 12.4 ns 12.4 ns 56448000
BM_to_chars_bad/10 5.13 ns 5.13 ns 137596000
BM_to_chars_bad/11 9.88 ns 9.88 ns 69015000
BM_to_chars_bad/12 10.8 ns 10.8 ns 63990000
BM_to_chars_bad/13 10.7 ns 10.7 ns 65066000
BM_to_chars_bad/14 9.71 ns 9.71 ns 71775000
BM_to_chars_bad/15 9.18 ns 9.18 ns 75267000
BM_to_chars_bad/16 6.12 ns 6.12 ns 115000000
BM_to_chars_bad/17 10.7 ns 10.7 ns 65504000
BM_to_chars_bad/18 10.6 ns 10.6 ns 65685000
BM_to_chars_bad/19 9.98 ns 9.98 ns 69894000
BM_to_chars_bad/20 9.74 ns 9.74 ns 72098000
BM_to_chars_bad/21 9.25 ns 9.25 ns 75184000
BM_to_chars_bad/22 9.10 ns 9.10 ns 75602000
BM_to_chars_bad/23 9.48 ns 9.48 ns 72824000
BM_to_chars_bad/24 9.27 ns 9.27 ns 75112000
BM_to_chars_bad/25 9.61 ns 9.61 ns 72080000
BM_to_chars_bad/26 9.72 ns 9.72 ns 72178000
BM_to_chars_bad/27 10.0 ns 10.0 ns 69733000
BM_to_chars_bad/28 10.3 ns 10.3 ns 67409000
BM_to_chars_bad/29 9.97 ns 9.97 ns 69193000
BM_to_chars_bad/30 10.1 ns 10.1 ns 69007000
BM_to_chars_bad/31 9.68 ns 9.68 ns 72232000
BM_to_chars_bad/32 8.99 ns 8.99 ns 76825000
BM_to_chars_bad/33 8.82 ns 8.82 ns 79293000
BM_to_chars_bad/34 8.64 ns 8.64 ns 80441000
BM_to_chars_bad/35 8.96 ns 8.96 ns 75320000
BM_to_chars_bad/36 8.87 ns 8.87 ns 77293000

```

After
```
--------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------
BM_to_chars_good/2 14.7 ns 14.7 ns 47583000
BM_to_chars_good/3 101 ns 101 ns 6901000
BM_to_chars_good/4 68.4 ns 68.4 ns 10088000
BM_to_chars_good/5 58.2 ns 58.2 ns 12007000
BM_to_chars_good/6 51.1 ns 51.1 ns 13687000
BM_to_chars_good/7 45.6 ns 45.6 ns 15323000
BM_to_chars_good/8 14.6 ns 14.6 ns 47795000
BM_to_chars_good/9 40.7 ns 40.7 ns 17371000
BM_to_chars_good/10 7.48 ns 7.48 ns 90931000
BM_to_chars_good/11 37.6 ns 37.6 ns 18542000
BM_to_chars_good/12 35.2 ns 35.2 ns 19922000
BM_to_chars_good/13 34.9 ns 34.9 ns 20105000
BM_to_chars_good/14 33.5 ns 33.5 ns 20863000
BM_to_chars_good/15 31.9 ns 31.9 ns 22014000
BM_to_chars_good/16 11.7 ns 11.7 ns 60012000
BM_to_chars_good/17 28.9 ns 28.9 ns 24148000
BM_to_chars_good/18 29.0 ns 29.0 ns 24317000
BM_to_chars_good/19 28.7 ns 28.7 ns 24363000
BM_to_chars_good/20 28.1 ns 28.1 ns 24899000
BM_to_chars_good/21 27.5 ns 27.5 ns 25499000
BM_to_chars_good/22 26.9 ns 26.9 ns 25929000
BM_to_chars_good/23 26.2 ns 26.2 ns 26828000
BM_to_chars_good/24 25.1 ns 25.1 ns 27742000
BM_to_chars_good/25 25.3 ns 25.3 ns 27720000
BM_to_chars_good/26 25.2 ns 25.2 ns 27789000
BM_to_chars_good/27 25.3 ns 25.3 ns 27777000
BM_to_chars_good/28 25.3 ns 25.3 ns 27643000
BM_to_chars_good/29 25.3 ns 25.3 ns 27750000
BM_to_chars_good/30 25.4 ns 25.4 ns 27566000
BM_to_chars_good/31 25.4 ns 25.4 ns 27611000
BM_to_chars_good/32 25.8 ns 25.8 ns 27218000
BM_to_chars_good/33 25.7 ns 25.7 ns 27070000
BM_to_chars_good/34 26.1 ns 26.1 ns 26693000
BM_to_chars_good/35 26.4 ns 26.4 ns 26486000
BM_to_chars_good/36 26.3 ns 26.3 ns 26619000
BM_to_chars_bad/2 5.99 ns 5.99 ns 118787000
BM_to_chars_bad/3 14.3 ns 14.3 ns 48567000
BM_to_chars_bad/4 16.0 ns 16.0 ns 43239000
BM_to_chars_bad/5 12.6 ns 12.6 ns 55354000
BM_to_chars_bad/6 10.7 ns 10.7 ns 65491000
BM_to_chars_bad/7 14.4 ns 14.4 ns 48723000
BM_to_chars_bad/8 6.50 ns 6.50 ns 104967000
BM_to_chars_bad/9 12.0 ns 12.0 ns 56552000
BM_to_chars_bad/10 5.16 ns 5.16 ns 136380000
BM_to_chars_bad/11 10.5 ns 10.5 ns 66764000
BM_to_chars_bad/12 10.7 ns 10.7 ns 65534000
BM_to_chars_bad/13 11.0 ns 11.0 ns 63426000
BM_to_chars_bad/14 9.90 ns 9.90 ns 68575000
BM_to_chars_bad/15 9.52 ns 9.52 ns 70932000
BM_to_chars_bad/16 6.14 ns 6.14 ns 111762000
BM_to_chars_bad/17 10.6 ns 10.6 ns 65883000
BM_to_chars_bad/18 10.5 ns 10.5 ns 67606000
BM_to_chars_bad/19 9.96 ns 9.96 ns 68898000
BM_to_chars_bad/20 9.40 ns 9.41 ns 73116000
BM_to_chars_bad/21 9.12 ns 9.12 ns 78647000
BM_to_chars_bad/22 8.95 ns 8.95 ns 80211000
BM_to_chars_bad/23 9.50 ns 9.49 ns 73571000
BM_to_chars_bad/24 9.29 ns 9.29 ns 74690000
BM_to_chars_bad/25 9.65 ns 9.65 ns 72877000
BM_to_chars_bad/26 9.78 ns 9.78 ns 70171000
BM_to_chars_bad/27 10.1 ns 10.1 ns 69543000
BM_to_chars_bad/28 10.4 ns 10.4 ns 67582000
BM_to_chars_bad/29 10.00 ns 10.00 ns 70806000
BM_to_chars_bad/30 9.99 ns 9.99 ns 70340000
BM_to_chars_bad/31 9.56 ns 9.56 ns 74159000
BM_to_chars_bad/32 8.97 ns 8.97 ns 78052000
BM_to_chars_bad/33 8.86 ns 8.86 ns 78586000
BM_to_chars_bad/34 8.81 ns 8.81 ns 78562000
BM_to_chars_bad/35 8.90 ns 8.90 ns 77384000
BM_to_chars_bad/36 9.04 ns 9.04 ns 77263000

```

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Lets to_chars use header implementation.

This removes the duplicated code from the dylib. Instead the dylib will
call the new functions in the header. Since this code is unneeded it's
remov

[libc++] Lets to_chars use header implementation.

This removes the duplicated code from the dylib. Instead the dylib will
call the new functions in the header. Since this code is unneeded it's
removed from the unstable ABI.

Depends on D125704

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Make to_chars base 10 header only.

The functions to_chars and from_chars should offer 128-bit support. This
is the first step to implement 128-bit version of to_chars. Before
implementing 1

[libc++] Make to_chars base 10 header only.

The functions to_chars and from_chars should offer 128-bit support. This
is the first step to implement 128-bit version of to_chars. Before
implementing 128-bit support the current code will be polished.

This moves the code from the dylib to the header in prepartion of

P2291 "Add Constexpr Modifiers to Functions to_chars and from_chars for
Integral Types in <charconv> Header"

Note some more cleanups will be done in follow-up commits
- Remove the _LIBCPP_AVAILABILITY_TO_CHARS from to_chars. With all code
in the header the availablilty macro is no longer needed. This
requires enabling the unit tests for additional platforms.
- The code in the dylib can switch to using the header implementation.
This allows removing the code duplicated in the header and the dylib.

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/inclu

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

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

show more ...

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ry

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .

Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.

This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .

Notes:

* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)

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

show more ...

Revert "Microsoft's floating-point to_chars powered by Ryu and Ryu Printf"

This reverts commit a8025e06fc0f2fe1bbee9e1a6f15c336bfbdcb05 since
it triggers PR52584 with debug info enabled.

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ry

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .

Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.

This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .

Notes:

* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)

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

show more ...

[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 st

[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.

show more ...

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

Differential Revis

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

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

show more ...

[libc++] Mark __u64toa and __u32toa as noexcept

The two functions don't throw, and the generated code is better when
we explicitly tell the compiler that the functions are noexcept. This
isn't an AB

[libc++] Mark __u64toa and __u32toa as noexcept

The two functions don't throw, and the generated code is better when
we explicitly tell the compiler that the functions are noexcept. This
isn't an ABI break because the signatures of the functions stay the
same with or without noexcept.

Fixes https://llvm.org/PR46016

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

show more ...

[libc++] Fix leading zeros in std::to_chars

Summary:
It is a bugfix proposal for https://bugs.llvm.org/show_bug.cgi?id=42166.

`std::to_chars` appends leading zeros if input 64-bit value has 9, 10 o

[libc++] Fix leading zeros in std::to_chars

Summary:
It is a bugfix proposal for https://bugs.llvm.org/show_bug.cgi?id=42166.

`std::to_chars` appends leading zeros if input 64-bit value has 9, 10 or 11 digits.
According to documentation `std::to_chars` must not append leading zeros:
https://en.cppreference.com/w/cpp/utility/to_chars

Changeset should not affect `std::to_chars` performance:
http://quick-bench.com/CEpRs14xxA9WLvkXFtaJ3TWOVAg

Unit test that `std::from_chars` supports compatibility for both `std::to_chars` outputs (previous and fixed one) already exists:
https://github.com/llvm-mirror/libcxx/blob/1f60111b597e5cb80a4513ec86f79b7e137f7793/test/std/utilities/charconv/charconv.from.chars/integral.pass.cpp#L63

Reviewers: lichray, mclow.lists, ldionne, EricWF

Reviewed By: lichray, mclow.lists

Subscribers: zoecarver, christof, dexonsmith, libcxx-commits

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

llvm-svn: 362967

show more ...

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

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

show more ...

[libc++][C++17] Elementary string conversions for integral types

Summary:
Major QoI considerations:

- The facility is backported to C++14, same as libstdc++.
- Efforts have been made to minimize th

[libc++][C++17] Elementary string conversions for integral types

Summary:
Major QoI considerations:

- The facility is backported to C++14, same as libstdc++.
- Efforts have been made to minimize the header dependencies.
- The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome.

Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`.

References:
https://wg21.link/p0067r5
https://wg21.link/p0682r1

Reviewers: mclow.lists, EricWF

Reviewed By: mclow.lists

Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits

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

llvm-svn: 338479

show more ...