Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
b9a2658a |
| 21-Dec-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)
This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)
This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the RFC, we initially proposed selecting the right headers from the Clang driver, however consensus seemed to steer towards handling this in the library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public header look like this:
``` // inside <vector> #ifdef _LIBCPP_CXX03_LANG # include <__cxx03/vector> #else // normal <vector> content #endif ```
In most cases, public headers are simple umbrella headers so there isn't much code in the #else branch. In other cases, the #else branch contains the actual implementation of the header.
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
c166a9c7 |
| 10-Dec-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Add #if 0 block to all the top-level headers (#119234)
Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a sep
[libc++] Add #if 0 block to all the top-level headers (#119234)
Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead.
This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
d6832a61 |
| 05-Sep-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++][modules] Modularize <cstddef> (#107254)
Many headers include `<cstddef>` just for size_t, and pulling in
additional content (e.g. the traits used for std::byte) is unnecessary.
To solve t
[libc++][modules] Modularize <cstddef> (#107254)
Many headers include `<cstddef>` just for size_t, and pulling in
additional content (e.g. the traits used for std::byte) is unnecessary.
To solve this problem, this patch splits up `<cstddef>` into
subcomponents so that headers can include only the parts that they
actually require.
This has the added benefit of making the modules build a lot stricter
with respect to IWYU, and also providing a canonical location where we
define `std::size_t` and friends (which were previously defined in
multiple headers like `<cstddef>` and `<ctime>`).
After this patch, there's still many places in the codebase where we
include `<cstddef>` when `<__cstddef/size_t.h>` would be sufficient.
This patch focuses on removing `<cstddef>` includes from __type_traits
to make these headers non-circular with `<cstddef>`. Additional
refactorings can be tackled separately.
show more ...
|
Revision tags: 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 |
|
#
37dca605 |
| 29-Feb-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Clean up includes of <__assert> (#80091)
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
th
[libc++] Clean up includes of <__assert> (#80091)
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
show more ...
|
Revision tags: 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 |
|
#
e8cb3559 |
| 04-Feb-2023 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Move constexpr <cstring> functions into their own headers and remove unused <cstring> includes
Reviewed By: ldionne, Mordante, #libc, #libc_abi
Spies: libcxx-commits
Differential Revision
[libc++] Move constexpr <cstring> functions into their own headers and remove unused <cstring> includes
Reviewed By: ldionne, Mordante, #libc, #libc_abi
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D143329
show more ...
|
Revision tags: llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
72173469 |
| 07-Dec-2022 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Refactor char_traits
This allows us to reuse workarounds for compilers that don't provide the builtins or constexpr support.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
D
[libc++] Refactor char_traits
This allows us to reuse workarounds for compilers that don't provide the builtins or constexpr support.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D139555
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
#
8cedff10 |
| 08-Aug-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Diagnose when header search paths are set up incorrectly
An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly w
[libc++] Diagnose when header search paths are set up incorrectly
An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add `-isystem <some-toolchain>/usr/include`, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly.
In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors.
Differential Revision: https://reviews.llvm.org/D131441
show more ...
|
Revision tags: 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 |
|
#
385cc25a |
| 25-Mar-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[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 ...
|
Revision tags: 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 |
|
#
fa6b9e40 |
| 02-Feb-2022 |
Arthur O'Dwyer <arthur.j.odwyer@gmail.com> |
[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 ...
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
eb8650a7 |
| 17-Nov-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[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 ...
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
#
87dd5198 |
| 24-Aug-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[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 Cl
[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
show more ...
|
Revision tags: 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 |
|
#
a9c9183c |
| 02-Jun-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Use the using_if_exists attribute when provided
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when the compiler supports it. This makes it easier to port libc++ on to
[libc++] Use the using_if_exists attribute when provided
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when the compiler supports it. This makes it easier to port libc++ on top of new platforms that don't fully support the C Standard library.
Previously, libc++ would fail to build when trying to import a missing declaration in a <cXXXX> header. With the attribute, the declaration will simply not be imported into namespace std, and hence it won't be available for libc++ to use. In many cases, the declarations were *not* actually required for libc++ to work (they were only surfaced for users to use them as std::XXXX), so not importing them into namespace std is acceptable.
The same thing could be achieved by conscious usage of `#ifdef` along with platform detection, however that quickly creates a maintenance problem as libc++ is ported to new platforms. Furthermore, this problem is exacerbated when mixed with vendor internal-only platforms, which can lead to difficulties maintaining a downstream fork of the library.
For the time being, we only use the using_if_exists attribute when it is supported. At some point in the future, we will start removing #ifdef paths that are unnecessary when the attribute is supported, and folks who need those #ifdef paths will be required to use a compiler that supports the attribute.
[1]: http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html
Differential Revision: https://reviews.llvm.org/D90257
show more ...
|
Revision tags: llvmorg-12.0.1-rc1 |
|
#
4cd6ca10 |
| 20-Apr-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[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, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, 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, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
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: 351636
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, 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, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3 |
|
#
5fd17ab1 |
| 10-Feb-2016 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from <string.h> and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from <wchar.h> to provide a const-correct overload set even when the
Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from <string.h> and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from <wchar.h> to provide a const-correct overload set even when the underlying C library does not.
This change adds a new macro, _LIBCPP_PREFERRED_OVERLOAD, which (if defined) specifies that a given overload is a better match than an otherwise equally good function declaration without the overload. This is implemented in modern versions of Clang via __attribute__((enable_if)), and not elsewhere.
We use this new macro to define overloads in the global namespace for these functions that displace the overloads provided by the C library, unless we believe the C library is already providing the correct signatures.
llvm-svn: 260337
show more ...
|
Revision tags: llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
#
25cb3209 |
| 29-Oct-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Revert r249929 ("Split <string.h> out of <cstring>").
This change caused problems when building code like povray that: a) uses 'using namespace std;' b) is built on an environment where the C librar
Revert r249929 ("Split <string.h> out of <cstring>").
This change caused problems when building code like povray that: a) uses 'using namespace std;' b) is built on an environment where the C library provides the "wrong" (non-const-correct) interface for the str* functions c) makes an unqualified call to one of those str* functions
A patch is out for review to add a facility to fix this (and to give the correct signatures for these functions whenever possible, even when the C library does not do so). This revert is expected to be temporary.
llvm-svn: 251665
show more ...
|
#
da231b4a |
| 10-Oct-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Split <string.h> out of <cstring>.
Also fix the overload set for the five functions whose signatures change in the case where we can fix it. This is already covered by existing tests for the affecte
Split <string.h> out of <cstring>.
Also fix the overload set for the five functions whose signatures change in the case where we can fix it. This is already covered by existing tests for the affected systems.
llvm-svn: 249929
show more ...
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2 |
|
#
e0cf3b9a |
| 24-Jun-2015 |
Ed Schouten <ed@nuxi.nl> |
Make support for thread-unsafe C functions optional.
One of the aspects of CloudABI is that it aims to help you write code that is thread-safe out of the box. This is very important if you want to w
Make support for thread-unsafe C functions optional.
One of the aspects of CloudABI is that it aims to help you write code that is thread-safe out of the box. This is very important if you want to write libraries that are easy to reuse. For CloudABI we decided to not provide the thread-unsafe functions. So far this is working out pretty well, as thread-unsafety issues are detected really early on.
The following patch adds a knob to libc++, _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS, that can be set to disable thread-unsafe functions that can easily be avoided in practice. The following functions are not thread-safe:
- <clocale>: locale handles should be preferred over setlocale(). - <cstdlib>: mbrlen(), mbrtowc() and wcrtomb() should be preferred over their non-restartable counterparts. - <ctime>: asctime(), ctime(), gmtime() and localtime() are not thread-safe. The first two are also deprecated by POSIX.
Differential Revision: http://reviews.llvm.org/D8703 Reviewed by: marshall
llvm-svn: 240527
show more ...
|
Revision tags: llvmorg-3.6.2-rc1 |
|
#
3ca2099f |
| 02-Jun-2015 |
Marshall Clow <mclow.lists@gmail.com> |
Revert changes inadvertantly committed
llvm-svn: 238880
|
#
ef96861d |
| 02-Jun-2015 |
Marshall Clow <mclow.lists@gmail.com> |
Move uncaught_exeption() definition inside the #ifdef block like uncaught_exceptions()
llvm-svn: 238879
|
Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1, llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1 |
|
#
0be8f64c |
| 01-Aug-2013 |
Howard Hinnant <hhinnant@apple.com> |
Nico Rieck: Currently _MSC_VER and _WIN32 are used to guard code which is MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can also define _MSC_VER, and MSVCRT is not necessarily t
Nico Rieck: Currently _MSC_VER and _WIN32 are used to guard code which is MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can also define _MSC_VER, and MSVCRT is not necessarily the only C runtime, these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using _MSC_VER, excluding Clang. - _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
llvm-svn: 187593
show more ...
|
Revision tags: llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1 |
|
#
98381453 |
| 08-Apr-2013 |
Howard Hinnant <hhinnant@apple.com> |
Change <cwchar> and <cstring> to look out for flags which may or may not be set by the C headers <wchar.h> and <string.h> indicating C support for the C++-altered wcschr, wcspbrk, wcsrchr, wcsstr, wm
Change <cwchar> and <cstring> to look out for flags which may or may not be set by the C headers <wchar.h> and <string.h> indicating C support for the C++-altered wcschr, wcspbrk, wcsrchr, wcsstr, wmemchr, strchr, strpbrk, strrchr, memchr, and strstr. This was already done in <cstring> for other platforms using other flags, so just had to add one more flag to the list there.
llvm-svn: 179041
show more ...
|
Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1, llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
#
14c25b80 |
| 29-Feb-2012 |
David Chisnall <csdavec@swan.ac.uk> |
Solaris port. Currently sees around 200 test failures, mostly related to Solaris not providing some of the locales that the test suite uses.
Note: This depends on an xlocale (partial) implementatio
Solaris port. Currently sees around 200 test failures, mostly related to Solaris not providing some of the locales that the test suite uses.
Note: This depends on an xlocale (partial) implementation for Solaris and a couple of fixed standard headers. These will be committed to a branch later today.
llvm-svn: 151720
show more ...
|
Revision tags: llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2 |
|
#
e4383379 |
| 22-Oct-2011 |
Howard Hinnant <hhinnant@apple.com> |
More windows port work by Ruben Van Boxem
llvm-svn: 142732
|
Revision tags: llvmorg-3.0.0-rc1 |
|
#
073458b1 |
| 17-Oct-2011 |
Howard Hinnant <hhinnant@apple.com> |
Windows support by Ruben Van Boxem.
llvm-svn: 142235
|