[libc++] Define legacy symbols for inline functions at a finer-grained level

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in la

[libc++] Define legacy symbols for inline functions at a finer-grained level

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).

However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.

This should solve some of the issues encountered in D65667.

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

show more ...

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

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

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

[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++] NFC: Normalize `#endif //` comment indentation

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

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++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY

Summary: As suggested by Marshall in https://reviews.llvm.org/D49914

Reviewers: mclow.lists, EricWF

[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY

Summary: As suggested by Marshall in https://reviews.llvm.org/D49914

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

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

llvm-svn: 338475

show more ...

Rework libcxx strerror_r handling.

The set of #ifdefs used to handle the two incompatible variants of
strerror_r were not complete (they didn't handle newlib appropriately).

Rather than attempting

Rework libcxx strerror_r handling.

The set of #ifdefs used to handle the two incompatible variants of
strerror_r were not complete (they didn't handle newlib appropriately).

Rather than attempting to make the ifdefs more complex, make them
unnecessary by choosing which behavior to use dependent upon the
return type.

Reviewers: waltl

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

llvm-svn: 308528

show more ...

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

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

show more ...

Recommit [libcxx] Never use <cassert> within libc++

It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`.
This patch remove all uses of `assert` from within libc++ and

Recommit [libcxx] Never use <cassert> within libc++

It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`.
This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.

Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default,
because the standard library should not be aborting user programs unless explicitly asked to.

llvm-svn: 294107

show more ...

Revert "[libcxx] Never use <cassert> within libc++"

This reverts commit r292883. Unfortunately <string_view> uses
_LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib
build. I'll inv

Revert "[libcxx] Never use <cassert> within libc++"

This reverts commit r292883. Unfortunately <string_view> uses
_LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib
build. I'll investigate more tomorrow.

llvm-svn: 292923

show more ...

[libcxx] Never use <cassert> within libc++

Summary:
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and

[libcxx] Never use <cassert> within libc++

Summary:
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.

Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to.

Reviewers: mclow.lists, compnerd, smeenai

Reviewed By: mclow.lists

Subscribers: mgorny, cfe-commits

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

llvm-svn: 292883

show more ...

Add ABI option to remove recently inlined __shared_count functions from the library.

In order to allow inlining of previously out-of-line functions without an ABI break
libc++ provides legacy defini

Add ABI option to remove recently inlined __shared_count functions from the library.

In order to allow inlining of previously out-of-line functions without an ABI break
libc++ provides legacy definitions in the dylib that old programs can
continue to use. Unfortunatly Windows link.exe detects this hack and diagnoses the duplicate
definitions.

This patch disable the duplicate definitions on Windows by adding an ABI option
which disables all "legacy out-of-line symbols"

llvm-svn: 292190

show more ...

clean up use of _WIN32

Replace the use of _WIN32 in libc++. Replace most use with a C runtime
check _LIBCPP_MSVCRT or the new _LIBCPP_WIN32 to indicate that we are
using the Win32 API. Use a new _LI

clean up use of _WIN32

Replace the use of _WIN32 in libc++. Replace most use with a C runtime
check _LIBCPP_MSVCRT or the new _LIBCPP_WIN32 to indicate that we are
using the Win32 API. Use a new _LIBCPP_WCHAR_IS_UCS2 to indicate that we
are on an environment that has a short wchar_t.

llvm-svn: 290910

show more ...

system_error: provide a thread safe stringification for Windows

Provide a strerror_r replacement for Windows. This is needed to build
libc++ for Windows with threading.

llvm-svn: 290851

Introduce _LIBCPP_DEPRECATED_ABI_EXTERNAL_ERROR_CATEGORY_CONSTRUCTOR ABI option.

Currently libc++ compiles a special version of error_category()
into the dylib. This definition is no longer needed,

Introduce _LIBCPP_DEPRECATED_ABI_EXTERNAL_ERROR_CATEGORY_CONSTRUCTOR ABI option.

Currently libc++ compiles a special version of error_category()
into the dylib. This definition is no longer needed, and doesn't
work on Windows due to dllimport/dllexport semantics.

For those reasons this patch introduces an option to
disable/enable this definition. By default the definition
is provided in ABI v1 except on windows. This patch
also addresses D28210.

llvm-svn: 290840

show more ...

system_error: use strerror_r only for threaded code

When building libc++ without threading, strerror_r is not used. Define
the code only when threading is enabled. This allows us to build
system_e

system_error: use strerror_r only for threaded code

When building libc++ without threading, strerror_r is not used. Define
the code only when threading is enabled. This allows us to build
system_error for Windows, which ATM doesn't build with threading.

llvm-svn: 290791

show more ...

Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these function

Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these functions everywhere instead of assert()ing when exceptions are disabled. WARNING: This is a behavior change - but only with exceptions disabled. Reviewed as: https://reviews.llvm.org/D23855.

llvm-svn: 279744

show more ...

Add an Android version check for GNU strerror_r.

Summary:
Android didn't gain GNU's strerror_r until Marshmallow. If we're
building libc++ against something older (we build the NDK library
against t

Add an Android version check for GNU strerror_r.

Summary:
Android didn't gain GNU's strerror_r until Marshmallow. If we're
building libc++ against something older (we build the NDK library
against the oldest release we support, currently Gingerbread), fall
back to the POSIX version.

Reviewers: mclow.lists, EricWF

Subscribers: tberghammer, danalbert, srhines, cfe-commits

Differential Revision: http://reviews.llvm.org/D21402

llvm-svn: 272827

show more ...

Fix syntax error in r272640.

llvm-svn: 272641

Fix error checking for strerror_r implementations that return the error code.

llvm-svn: 272640

Make system_error::message() thread safe. Fixes PR25598.

Summary:
system_error::message() uses `strerror` for the generic and system categories. This function is not thread safe.

The fix is to use

Make system_error::message() thread safe. Fixes PR25598.

Summary:
system_error::message() uses `strerror` for the generic and system categories. This function is not thread safe.

The fix is to use `strerror_r`. It has been available since 2001 for GNU libc and since BSD 4.4 on FreeBSD/OS X.
On platforms with GNU libc the extended version is used which always returns a valid string, even if an error occurs.

In single-threaded builds `strerror` is still used.

See https://llvm.org/bugs/show_bug.cgi?id=25598

Reviewers: majnemer, mclow.lists

Subscribers: erik65536, cfe-commits, emaste

Differential Revision: http://reviews.llvm.org/D20903

llvm-svn: 272633

show more ...

Move atomic_support.h and config_elast.h into src/include

llvm-svn: 245354

Fix -Wpessimizing-move warning by remove the call to std::move.

llvm-svn: 236265