|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
2ae52326 |
| 08-Jun-2021 |
Louis Dionne <[email protected]> |
[libc++] Towards a simpler extern template story in libc++
The flexibility around extern template instantiation declarations in libc++ result in a very complicated model, especially when support for
[libc++] Towards a simpler extern template story in libc++
The flexibility around extern template instantiation declarations in libc++ result in a very complicated model, especially when support for slightly different configurations (like the debug mode or assertions in the dylib) are taken into account. That results in unexpected bugs like http://llvm.org/PR50534 (and there have been multiple similar bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which I don't think is fundamental. Indeed, the motivation for that knob was to avoid taking a dependency on the library, however that can be done better by linking against the static library instead. And in fact, some parts of the headers will always depend on things defined in the library, which defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
show more ...
|
| #
385cc25a |
| 25-Mar-2022 |
Louis Dionne <[email protected]> |
[libc++] Ensure that all public C++ headers include <__assert>
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any publ
[libc++] Ensure that all public C++ headers include <__assert>
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
show more ...
|
| #
52915d78 |
| 05-Mar-2022 |
Nikolas Klauser <[email protected]> |
[libc++] Granularize <utility> includes
Reviewed By: ldionne, #libc
Spies: EricWF, libcxx-commits, arphaman
Differential Revision: https://reviews.llvm.org/D120466
|
| #
fa6b9e40 |
| 02-Feb-2022 |
Arthur O'Dwyer <[email protected]> |
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D1188
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D118800
show more ...
|
| #
bd6e6846 |
| 22-Dec-2021 |
Mark de Wever <[email protected]> |
[libc++] Add the version header to all headers.
Some headers which require the version header depend on other headers to provide it. Include the version header in all top-level headers to make sure
[libc++] Add the version header to all headers.
Some headers which require the version header depend on other headers to provide it. Include the version header in all top-level headers to make sure a header cleanup can't remove the version header.
Note this doesn't add the version header to the c headers.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116172
show more ...
|
| #
eb8650a7 |
| 17-Nov-2021 |
Louis Dionne <[email protected]> |
[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 ...
|
| #
a8d1182f |
| 15-Jun-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Remove some _LIBCPP_CXX03_LANG from iostreams headers.
With the STL containers, I didn't enable move operations in C++03 mode because that would change the overload resolution for things th
[libc++] Remove some _LIBCPP_CXX03_LANG from iostreams headers.
With the STL containers, I didn't enable move operations in C++03 mode because that would change the overload resolution for things that today are copy operations. With iostreams, though, the copy operations aren't present at all, and so I see no problem with enabling move operations even in (Clang's greatly extended) C++03 mode.
Clang's C++03 mode does not support delegating constructors.
Differential Revision: https://reviews.llvm.org/D104310
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
bfbd73f8 |
| 19-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Alphabetize and include-what-you-use. NFCI.
Differential Revision: https://reviews.llvm.org/D102781
|
| #
4cd6ca10 |
| 20-Apr-2021 |
Louis Dionne <[email protected]> |
[libc++] NFC: Normalize `#endif //` comment indentation
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
| #
a11f8b1a |
| 19-Jan-2021 |
Marek Kurdej <[email protected]> |
[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++] [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
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
527a7fdf |
| 24-Nov-2020 |
Bruce Mitchener <[email protected]> |
[libc++] Replace several uses of 0 by nullptr
Differential Revision: https://reviews.llvm.org/D43159
|
| #
997d41cd |
| 21-Oct-2020 |
Louis Dionne <[email protected]> |
[libc++] Instantiate additional <iostream> members in the dylib
This commit adds new explicit instantiations for some classes in <iostream> in the library. This is done after noticing that many prog
[libc++] Instantiate additional <iostream> members in the dylib
This commit adds new explicit instantiations for some classes in <iostream> in the library. This is done after noticing that many programs that use streams end up containing weak definitions of these classes, which has a negative impact on both code size and load times (due to the need to resolve weak symbols at load time). Note that we are just adding the additional explicit instantiations for the `char` specializations, since the `wchar_t` specializations are not used as often, and as a result there wouldn't be a clear benefit.
This change is not an ABI break, since we are just adding additional symbols.
Differential Revision: https://reviews.llvm.org/D90677
show more ...
|
| #
4abb5196 |
| 09-Oct-2020 |
Louis Dionne <[email protected]> |
[libc++] NFCI: Define small methods of basic_stringstream inline
It greatly increases readability because defining the methods out-of-line involves a ton of boilerplate template declarations.
|
| #
12805513 |
| 09-Oct-2020 |
Louis Dionne <[email protected]> |
[libc++] Remove some workarounds for C++03
We don't support any compiler that doesn't support variadics and rvalue references in C++03 mode, so these workarounds can be dropped. There's still *a lot
[libc++] Remove some workarounds for C++03
We don't support any compiler that doesn't support variadics and rvalue references in C++03 mode, so these workarounds can be dropped. There's still *a lot* of cruft related to these workarounds, but I try to tackle a bit of it here and there.
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2 |
|
| #
2e719bc4 |
| 01-Feb-2019 |
Marshall Clow <[email protected]> |
add a test and a couple minor bug fixes for the implicit-signed-integer-truncation sanitizer. This is PR#40566
llvm-svn: 352926
|
|
Revision tags: llvmorg-8.0.0-rc1 |
|
| #
57b08b09 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
| #
7c3492b0 |
| 03-Aug-2018 |
Louis Dionne <[email protected]> |
[NFC][libc++] Consistently use spaces to indent
rdar://problem/19988944
llvm-svn: 338933
|
|
Revision tags: llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
| #
22c651c5 |
| 19-Dec-2017 |
Peter Collingbourne <[email protected]> |
libcxx: Fix for basic_stringbuf::seekoff() after r320604.
As a result of this change, the basic_stringbuf constructor that takes a mode ends up leaving __hm_ set to 0, causing the comparison "__hm_
libcxx: Fix for basic_stringbuf::seekoff() after r320604.
As a result of this change, the basic_stringbuf constructor that takes a mode ends up leaving __hm_ set to 0, causing the comparison "__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused the function to incorrectly return -1. The fix is to account for the possibility of __hm_ being 0 when computing the distance from __hm_ to the start of the string.
Differential Revision: https://reviews.llvm.org/D41319
llvm-svn: 321124
show more ...
|
| #
378ae52b |
| 13-Dec-2017 |
Zhihao Yuan <[email protected]> |
[libcxx] Fix basic_stringbuf constructor
Summary: [libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf constructor that takes ios_
[libcxx] Fix basic_stringbuf constructor
Summary: [libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf constructor that takes ios_base::openmode as follows: Effects: Constructs an object of class basic_stringbuf, initializing the base class with basic_streambuf(), and initializing mode with which. Postconditions: str() == "".
The default constructor of basic_streambuf shall initialize all its pointer member objects to null pointers [streambuf.cons]p1.
Currently libc++ calls "str(string_type());" in the aforementioned constructor setting basic_streambuf's pointers to a non-null value.
This patch removes the call (note that the postcondition str() == "" remains valid because __str_ is default-initialized) and adds a test checking that the basic_streambuf's pointers are null after construction.
Thanks Mikhail Maltsev for the patch.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40707
llvm-svn: 320604
show more ...
|
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1 |
|
| #
d90758e2 |
| 12-Sep-2017 |
Marshall Clow <[email protected]> |
Make pbump (internally) handle sizes bigger than MAX_INT. Fixes PR#33725 - thanks to Jonathan Wakely for the report
llvm-svn: 313031
|
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2 |
|
| #
a054f828 |
| 02-Aug-2017 |
Marshall Clow <[email protected]> |
Fix PR33727: std::basic_stringbuf only works with DefaultConstructible allocators. Thanks to Jonathan Wakely for the report and suggested fix
llvm-svn: 309838
|
|
Revision tags: llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3 |
|
| #
a016efb1 |
| 31-May-2017 |
Eric Fiselier <[email protected]> |
[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 an
[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
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
| #
f0aca21e |
| 18-Apr-2017 |
Eric Fiselier <[email protected]> |
Cleanup _LIBCPP_HAS_NO_<c++11-feature> in the input.output library
llvm-svn: 300626
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
| #
e2f2d1ed |
| 04-Jan-2017 |
Eric Fiselier <[email protected]> |
[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__((__typ
[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
show more ...
|
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
1e033439 |
| 16-Sep-2016 |
Eric Fiselier <[email protected]> |
Move _LIBCPP_INLINE_VISIBILITY to first declaration in sstream.
llvm-svn: 281691
|