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

[libc++] Rename *SAFE_STATIC to *CONSTINIT, and normalize its uses.

In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/f

[libc++] Rename *SAFE_STATIC to *CONSTINIT, and normalize its uses.

In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.

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

show more ...

[libcxx] Add deprecation notices to macros deprecated in P0883R2

When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc

[libcxx] Add deprecation notices to macros deprecated in P0883R2

When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc++ itself.

This takes care of both.

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

show more ...

[libc++] Change workaround for init_priority((100)) outside of system headers

We had previously been using a different workaround for pretending that
we were inside a system header, however it had s

[libc++] Change workaround for init_priority((100)) outside of system headers

We had previously been using a different workaround for pretending that
we were inside a system header, however it had some undesirable effects
on dependency parsing for build systems, as explained in [1].

This patch changes the workaround to use `#pragma GCC system_header`,
which shouldn't suffer from the same issue. Unfortunately, it is a lot
more verbose. The issue is that `#pragma GCC system_header` is ignored
when we are inside a source file, so we have to create a header just for
the sake of using it. IMO this seems like an artificial restriction
without much benefit, but investigating that is a different story.
For now, this should at least solve build system problems at the
cost of some readability.

[1]: https://reviews.llvm.org/D95972#3178968

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

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++] Use init_priority(100) when possible

Priorities below 101 are reserved for the implementation, so that's what
we should be using here. That is unfortunately only supported on more
recent ve

[libc++] Use init_priority(100) when possible

Priorities below 101 are reserved for the implementation, so that's what
we should be using here. That is unfortunately only supported on more
recent versions of Clang. See https://reviews.llvm.org/D31413 for details.

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

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++] Remove C++11 work-arounds in src.

Building libcxx requires at least C++17 so remove the old work-arounds.

Reviewed By: ldionne, #libc

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

Guard init_priority attribute within libc++

Not all platforms support priority attribute. I'm moving conditional definition of this attribute to `include/__config`.

Reviewed By: #libc, aaron.ballma

Guard init_priority attribute within libc++

Not all platforms support priority attribute. I'm moving conditional definition of this attribute to `include/__config`.

Reviewed By: #libc, aaron.ballman

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

show more ...

[libcxx{,abi}] Emit deplibs only when detected by CMake

This is a followup to 35bc5276ca3. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
d

[libcxx{,abi}] Emit deplibs only when detected by CMake

This is a followup to 35bc5276ca3. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
detects them, rather than based on explicit platform blacklist.

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

show more ...

Fix build in C++20

llvm-svn: 371863

[runtimes] Don't depend on libpthread on Android

r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Andro

[runtimes] Don't depend on libpthread on Android

r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.

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

llvm-svn: 366734

show more ...

[runtimes] Check if pragma comment(lib, ...) is supported first

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is C

[runtimes] Check if pragma comment(lib, ...) is supported first

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.

llvm-svn: 362055

show more ...

[runtimes] Support ELF dependent libraries feature

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthr

[runtimes] Support ELF dependent libraries feature

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.

This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.

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

llvm-svn: 362048

show more ...

LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"

Patch by Arthur O'Dwyer.
Reviewed as https://reviews.llvm.org/D47344

new_delete_resource().allocate(n, a) has basically two p

LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"

Patch by Arthur O'Dwyer.
Reviewed as https://reviews.llvm.org/D47344

new_delete_resource().allocate(n, a) has basically two permissible results:

* Return an appropriately sized and aligned block.
* Throw bad_alloc.

Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was
to return an appropriately sized but inappropriately under-aligned block. This is now fixed.

(This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't
trust the default resource to return appropriately aligned blocks, pretty much everything breaks.
For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't
care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.)

llvm-svn: 355763

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

Implement sized deallocation for std::allocator and friends.

Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should

Implement sized deallocation for std::allocator and friends.

Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).

This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.

On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.

Reviewers: ldionne, mclow.lists

Reviewed By: ldionne

Subscribers: rsmith, ckennelly, libcxx-commits, christof

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

llvm-svn: 345281

show more ...

Temporarily Revert "Implement sized deallocation for std::allocator and friends."

This is breaking the bots here (and related): http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu

Temporarily Revert "Implement sized deallocation for std::allocator and friends."

This is breaking the bots here (and related): http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-asan/builds/1428

This reverts commit r345214.

llvm-svn: 345239

show more ...

Implement sized deallocation for std::allocator and friends.

Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should

Implement sized deallocation for std::allocator and friends.

Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).

This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.

On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.

Reviewers: ldionne, mclow.lists

Reviewed By: ldionne

Subscribers: rsmith, ckennelly, libcxx-commits, christof

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

llvm-svn: 345214

show more ...

Fix PR38160 - init_priority attribute not supported by GCC on Apple.

This patch guards the use of __attribute__((init_priority(101)))
within memory_resource.cpp when building with compilers that don

Fix PR38160 - init_priority attribute not supported by GCC on Apple.

This patch guards the use of __attribute__((init_priority(101)))
within memory_resource.cpp when building with compilers that don't
support it. Specifically GCC on Apple platforms, and MSVC.

llvm-svn: 337205

show more ...

Fix PR22634 - std::allocator doesn't respect over-aligned types.

This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-align

Fix PR22634 - std::allocator doesn't respect over-aligned types.

This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.

__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).

When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.

This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.

llvm-svn: 328180

show more ...

[libc++] Tolerate presence of __deallocate macro

Summary:
On Windows the identifier `__deallocate` is defined as a macro by one of the Windows system headers. Previously libc++ worked around this by

[libc++] Tolerate presence of __deallocate macro

Summary:
On Windows the identifier `__deallocate` is defined as a macro by one of the Windows system headers. Previously libc++ worked around this by `#undef __deallocate` and generating a warning. However this causes the WIN32 version of `__threading_support` to always generate a warning on Windows. This is not OK.

This patch renames all usages of `__deallocate` internally as to not conflict with the macro.

Reviewers: mclow.lists, majnemer, rnk, rsmith, smeenai, compnerd

Subscribers: cfe-commits

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

llvm-svn: 291332

show more ...

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

memory_resource still needs init_priority when built with GCC 4.9

llvm-svn: 280585

Define _LIBCPP_SAFE_STATIC __attribute__((require_constant_initialization)), and apply it to memory_resource

llvm-svn: 280561