[libc++][NFC] Replace enable_if with __enable_if_t in a few places

Reviewed By: ldionne, #libc

Spies: jloser, libcxx-commits

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

[libc++] Revert "Protect users from relying on detail headers" & related changes

This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,
which were related to the original commit).

[libc++] Revert "Protect users from relying on detail headers" & related changes

This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.

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

show more ...

[libcxx][modules] protects users from relying on detail headers

libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that ou

[libcxx][modules] protects users from relying on detail headers

libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.

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

show more ...

Remove __uncvref; use __uncvref_t instead

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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

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

[libc++] Enable the optimized _IsSame on GCC as well as Clang.

However, there's a problem on both GCC and Clang: they can't mangle
`__is_same(T,U)` if it appears anywhere that affects mangling. That

[libc++] Enable the optimized _IsSame on GCC as well as Clang.

However, there's a problem on both GCC and Clang: they can't mangle
`__is_same(T,U)` if it appears anywhere that affects mangling. That's
a hard error. And it turns out that GCC puts dependent return types
into the mangling more aggressively than Clang, so for GCC's benefit
we need to avoid using raw `_IsSame` in the return type of
`swap(tuple&, tuple&)`. Therefore, make `__all` into a named type
instead of an alias.

If we ever need to support a compiler without the __is_same builtin,
we can make this an alias template for `is_same<T,U>::type`.

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

show more ...

[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs

Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs a

[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs

Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE
in favour of always using _LIBCPP_NODEBUG.

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

show more ...

[libc++] NFC: Normalize `#endif //` comment indentation

Refactor default constructor SFINAE in pair and tuple.

Refactor the recent implicit default constructor changes to match the
existing SFINAE style.

llvm-svn: 373263

Apply new meta-programming traits throughout the library.

The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use t

Apply new meta-programming traits throughout the library.

The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.

llvm-svn: 364160

show more ...

Apply [[nodebug]] to typedefs throughout the STL.

When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__f

Apply [[nodebug]] to typedefs throughout the STL.

When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__function::__alloc_func<remove_reference<void(&)()>::type,
allocator<remove_reference<void(&)()>, void()>::_Target` you see
`void(&)()` as the type of the variable in your debugger.

Removing all this SFINAE noise from debug info has huge binary size
wins, in addition to improving the readability.

For now this change is on by default. Users can override it by
specifying -D_LIBCPP_NODEBUG_TYPE=

llvm-svn: 363117

show more ...

[libc++] Declare std::tuple_element as struct instead of class

Similarly to https://reviews.llvm.org/rL350972, this revision changes
std::tuple_element from class to struct.

Fixes PR41331.
Thanks t

[libc++] Declare std::tuple_element as struct instead of class

Similarly to https://reviews.llvm.org/rL350972, this revision changes
std::tuple_element from class to struct.

Fixes PR41331.
Thanks to Jan Wilken Dörrie for the patch.

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

llvm-svn: 357411

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

Change from a to a . Fixes PR#39871.

llvm-svn: 350972

Cleanup remaining usages of _LIBCPP_HAS_NO_<c++11-feature> in tuple and utility

llvm-svn: 300644

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

Fix private inheritance in C++03 tuple_size

llvm-svn: 291032

[libcxx] Re-implement LWG 2770 again: Fix tuple_size to work with structured bindings

Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.

The PR for 2

[libcxx] Re-implement LWG 2770 again: Fix tuple_size to work with structured bindings

Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.

The PR for 2770 specifies tuple_size<T const> as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size<T const>` to be complete only if `tuple_size<T>` is also complete. Therefore this patch implements only provides the specialization `tuple_size<T CV>` iff `tuple_size<T>` is a complete type.

This fixes http://llvm.org/PR31513.

Reviewers: mclow.lists, rsmith, mpark

Subscribers: mpark, cfe-commits

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

llvm-svn: 291019

show more ...

Re-implement LWG 2770 - Fix tuple_size with structured bindings.

This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of

Re-implement LWG 2770 - Fix tuple_size with structured bindings.

This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.

llvm-svn: 290846

show more ...

Revert r289727 due to PR31384

This patch reverts the changes to tuple which fixed construction from
types derived from tuple. It breaks the code mentioned in llvm.org/PR31384.
I'll follow this commi

Revert r289727 due to PR31384

This patch reverts the changes to tuple which fixed construction from
types derived from tuple. It breaks the code mentioned in llvm.org/PR31384.
I'll follow this commit up with a test case.

llvm-svn: 289773

show more ...

[libcxx] Fix tuple construction/assignment from types derived from tuple/pair/array.

Summary:
The standard requires tuple have the following constructors:
```
tuple(tuple<OtherTypes...> const&);
tup

[libcxx] Fix tuple construction/assignment from types derived from tuple/pair/array.

Summary:
The standard requires tuple have the following constructors:
```
tuple(tuple<OtherTypes...> const&);
tuple(tuple<OtherTypes...> &&);
tuple(pair<T1, T2> const&);
tuple(pair<T1, T2> &&);
tuple(array<T, N> const&);
tuple(array<T, N> &&);
```
However libc++ implements these as a single constructor with the signature:
```
template <class TupleLike, enable_if_t<__is_tuple_like<TupleLike>::value>>
tuple(TupleLike&&);
```

This causes the constructor to reject types derived from tuple-like types; Unlike if we had all of the concrete overloads, because they cause the derived->base conversion in the signature.

This patch fixes this issue by detecting derived types and the tuple-like base they are derived from. It does this by creating an overloaded function with signatures for each of tuple/pair/array and checking if the possibly derived type can convert to any of them.

This patch fixes [PR17550]( https://llvm.org/bugs/show_bug.cgi?id=17550)

This patch

Reviewers: mclow.lists, K-ballo, mpark, EricWF

Subscribers: cfe-commits

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

llvm-svn: 289727

show more ...

Implement LWG 2770 - Make tuple_size<T> defined for all T

llvm-svn: 286779

Fix or suppress GCC warnings during build.

Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:

* Work aro

Fix or suppress GCC warnings during build.

Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:

* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.



Reviewers: EricWF

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

llvm-svn: 280007

show more ...

Check in SFINAE base class for use in optional/variant

llvm-svn: 278643

Implement the std::pair parts of "Improving pair and tuple". Completes N4387.

llvm-svn: 276605