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
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
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.
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
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
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
<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
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
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
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
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
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
Louis Dionne