[libc++][AIX] Correct the definition of __regex_word for AIX

Summary:
The patch changes the definition of __regex_word to 0x8000 for AIX because the current definition 0x80 clashes with ctype_base::

[libc++][AIX] Correct the definition of __regex_word for AIX

Summary:
The patch changes the definition of __regex_word to 0x8000 for AIX because the current definition 0x80 clashes with ctype_base::print (_ISPRINT is defined as 0x80 in AIX ctype.h).

Reviewed by: Mordante, hubert.reinterpretcast, libc++

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

show more ...

[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`

D127650 removed support for non-clang-based XL compilers, but left some
of the headers used only by this compiler and included under the
_

[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`

D127650 removed support for non-clang-based XL compilers, but left some
of the headers used only by this compiler and included under the
__IBMCPP__ macro. This change cleans this up by deleting these headers.

Reviewed By: hubert.reinterpretcast, fanbo-meng

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

show more ...

[libc++] Towards a simpler extern template story in libc++

The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for

[libc++] Towards a simpler extern template story in libc++

The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).

This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.

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

show more ...

[libc++] Minor emscripten changes from downstream

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

[libc++] Remove <utility> includes

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits, arphaman

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

[libc++] Granularize <utility> includes

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits, arphaman

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

[libcxx] Fix the ctype `is` (pointer version) function for Windows

Previously, this test snippet would report incorrect information:

F::mask m;
std::wstring in(L"\u00DA"); // LATIN CAPITAL

[libcxx] Fix the ctype `is` (pointer version) function for Windows

Previously, this test snippet would report incorrect information:

F::mask m;
std::wstring in(L"\u00DA"); // LATIN CAPITAL LETTER U WITH ACUTE
f.is(in.data(), in.data() + 1, &m);
// m & F::lower would be set

The single-character version of the `is` function wasn't
affected by this issue though.

Define `_LIBCPP_CTYPE_MASK_IS_COMPOSITE_ALPHA` for Windows,
as the `alpha` / `_ALPHA` constant is a mask consisting of
multiple bits set, which avoids setting `alpha` whenver any
of the bits is set, in the `do_is` implementation.

On Windows, with the "C" locale, wchars are classified according
to their Unicode interpretation, just as in the en_US.UTF-8 locale on
all platforms.

Due to the differing classification of some characters, the
`scan_is` and `scan_not` tests are quite annoying to fix, thus just
ifdef out some of the tests for the "C" locale there - the code gets
tested with the more standard en_US.UTF-8 locale anyway.

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

show more ...

[libc++] Use -I instead of -isystem to include headers in the test suite

Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normall

[libc++] Use -I instead of -isystem to include headers in the test suite

Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normally get if we included
the headers as user headers.

The goal of the test suite is normally to mirror as closely as possible
how users would use the library. Technically, this change goes against
that philosophy, since users should be using `-isystem` (if they ever
need to specify the libc++ path explicitly, which should be a rare
occurence). However, I believe fishing out additional warnings from
the headers provides more value, hence this change. Ideally, we'd be
able to still use `-isystem`, but instruct Clang to still emit warnings
from the libc++ headers (e.g. we could tell Clang to emit warnings in
any file inside `<...>/usr/include/c++/v1`).

Reviewed By: #libc, ldionne, #libc_abi

Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits

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

show more ...

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

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

[libcxx] [Windows] Pick a unique bit for __regex_word

The old `__regex_word` aliased the mask for `xdigit`, causing stray
test failures.

The diff may look surprising, as if the previous faulty valu

[libcxx] [Windows] Pick a unique bit for __regex_word

The old `__regex_word` aliased the mask for `xdigit`, causing stray
test failures.

The diff may look surprising, as if the previous faulty value had
been set specifically for Windows - but this is due to a restructuring
in 411c630bae0e0d50697651797709987e2cfea92d. Prior to that, there
were OS specific settings for some OSes, and one fallback used for
the rest (which turns out to not work for Windows).

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

show more ...

[SystemZ][z/OS][NFC] Remove extra symbol

[SystemZ][z/OS] ASCII/EBCDIC support with no coexistence

The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this pa

[SystemZ][z/OS] ASCII/EBCDIC support with no coexistence

The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this patch adds the char encoding sensitive changes but does not use inline namespaces as before. The use of namespaces to build both versions of the library, and localization of error messages will follow in a subsequent patch.

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

show more ...

[libc++] Alphabetize header #includes. NFCI.

The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

Differential Revision: https://revie

[libc++] Alphabetize header #includes. NFCI.

The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

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

show more ...

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commit

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commits

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

show more ...

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

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

show more ...

[libcxx] Remove the locale fallback for NuttX

Since these functions can handled by NuttX's libc now

Reviewed By: #libc, ldionne

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

[libc++] Alphabetize and include-what-you-use. NFCI.

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

[libcxx] Make the visibility attributes consistent for __narrow_to_utf8/__widen_from_utf8

Use the same visiblity attributes as for all other template
specializations in the same file; declare the sp

[libcxx] Make the visibility attributes consistent for __narrow_to_utf8/__widen_from_utf8

Use the same visiblity attributes as for all other template
specializations in the same file; declare the specialization itself
using _LIBCPP_TYPE_VIS, and don't use _LIBCPP_EXPORTED_FROM_ABI on
the destructor. Methods that are excluded from the ABI are marked
with _LIBCPP_INLINE_VISIBILITY.

This makes the vtable exported from DLL builds of libc++. Practically,
it doesn't make any difference for the CI configuration, but it
can make a difference in mingw setups.

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

show more ...

[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g

This was raised in D94511.

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

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

[libc++] Rename include/support to include/__support

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

Differentia

[libc++] Rename include/support to include/__support

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

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

show more ...

[libc++] Unbreak the debug mode

When the Debug mode is enabled, we disable extern declarations because we
don't want to use the functions compiled in the library, which might not
have had the debug

[libc++] Unbreak the debug mode

When the Debug mode is enabled, we disable extern declarations because we
don't want to use the functions compiled in the library, which might not
have had the debug mode enabled when built. However, some extern declarations
need to be kept, because code correctness depends on it.

31e820378b8a removed those declarations, which had the unintended
consequence of breaking the debug build. This commit fixes that by
re-introducing a separate macro for the required extern declarations,
and adds a comment so that we don't fall into that trap in the future.

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

show more ...

Fix libc++ clang-cl build, swap attribute order

Clang insists that __attribute__ attributes precede __declspec
attributes. This is a longstanding known issue:
https://llvm.org/pr24559. Re-order the

Fix libc++ clang-cl build, swap attribute order

Clang insists that __attribute__ attributes precede __declspec
attributes. This is a longstanding known issue:
https://llvm.org/pr24559. Re-order the visibility and deprecation macros
to fix the build.

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

show more ...