[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++] Fix undefined behavior in `std::filebuf`

Fixes https://github.com/llvm/llvm-project/issues/49267.
Fixes https://github.com/llvm/llvm-project/issues/49282.
Fixes https://github.com/llvm/llvm

[libc++] Fix undefined behavior in `std::filebuf`

Fixes https://github.com/llvm/llvm-project/issues/49267.
Fixes https://github.com/llvm/llvm-project/issues/49282.
Fixes https://github.com/llvm/llvm-project/issues/49789.

Reviewed By: ldionne

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

show more ...

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

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

show more ...

[libc++] Granularize <utility> includes

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits, arphaman

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

[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++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

show more ...

[libc++] Implement P0627R6 (Function to mark unreachable code)

Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

Differential Revision: https://reviews.

[libc++] Implement P0627R6 (Function to mark unreachable code)

Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

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

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

[libc++] Add the version header to all headers.

Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure

[libc++] Add the version header to all headers.

Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure a header cleanup can't remove the version header.

Note this doesn't add the version header to the c headers.

Reviewed By: #libc, Quuxplusone, ldionne

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

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++] Remove support for CloudABI, which has been abandoned

Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI
project has been abandoned. This patch removes a bunch of Cl

[libc++] Remove support for CloudABI, which has been abandoned

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

show more ...

[libc++] Remove some _LIBCPP_CXX03_LANG from iostreams headers.

With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things th

[libc++] Remove some _LIBCPP_CXX03_LANG from iostreams headers.

With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.

Clang's C++03 mode does not support delegating constructors.

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

show more ...

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

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

[libc++] Alphabetize header inclusions and include-what-you-use <__debug>. NFCI.

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

[libc++] add `inline` for __open's definition in ifstream and ofstream

Summary:

When building with gcc on AIX, it seems that gcc does not like the
`always_inline` without the `inline` keyword.
So a

[libc++] add `inline` for __open's definition in ifstream and ofstream

Summary:

When building with gcc on AIX, it seems that gcc does not like the
`always_inline` without the `inline` keyword.
So adding the inline keywords in for __open in ifstream and ofstream.
That will also make it consistent with __open in basic_filebuf
(it seems we added `inline` there before for gcc build as well).

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

show more ...

[libc++] Move checks for newlib to actually work

The checks did not work in __config, since no header defining
`_NEWLIB_VERSION` was included before. This patch moves the two
checks for newlib to th

[libc++] Move checks for newlib to actually work

The checks did not work in __config, since no header defining
`_NEWLIB_VERSION` was included before. This patch moves the two
checks for newlib to the headers that actually need it - and after
they already include relevant headers.

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

show more ...

[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent

Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes t

[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent

Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes the
setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where
the whole library is aware of the setting and features that depend on
<filesystem> won't be provided at all. The test suite is also properly
annotated such that tests that depend on <filesystem> are disabled when
the library doesn't support it.

This is an alternative to https://llvm.org/D94824, but also an improvement
along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to
make for a while.

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

show more ...

[libc++] ADL-proof by adding _VSTD:: qualifications to memmove etc.

Generally these calls aren't vulnerable to ADL because they involve only
primitive types. The ones in <list> and <vector> drag in

[libc++] ADL-proof by adding _VSTD:: qualifications to memmove etc.

Generally these calls aren't vulnerable to ADL because they involve only
primitive types. The ones in <list> and <vector> drag in namespace std
but that's OK; the ones in <fstream> and <strstream> are vulnerable
iff `CharT` is an enum type, which seems far-fetched.
But absolutely zero of them *need* ADL to happen; so in my opinion
they should all be consistently qualified, just like calls to any
other (non-user-customizable) functions in namespace std.

Also: Include <cstring> and <cwchar> in <__string>.
We seemed to be getting lucky that <memory> included <iterator>
included <iosfwd> included <wchar.h>. That gave us the
global-namespace `wmemmove`, but not `_VSTD::wmemmove`.
This is now fixed.

I didn't touch these headers:
<ext/__hash> uses strlen, safely
<support/ibm/locale_mgmt_aix.h> uses memcpy, safely
<string.h> uses memchr and strchr, safely
<wchar.h> uses wcschr, safely
<__bsd_locale_fallbacks.h> uses wcsnrtombs, safely

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

show more ...

[libc++] Replace several uses of 0 by nullptr

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

[libc++] Instantiate additional <iostream> members in the dylib

This commit adds new explicit instantiations for some classes in <iostream>
in the library. This is done after noticing that many prog

[libc++] Instantiate additional <iostream> members in the dylib

This commit adds new explicit instantiations for some classes in <iostream>
in the library. This is done after noticing that many programs that use
streams end up containing weak definitions of these classes, which has a
negative impact on both code size and load times (due to the need to
resolve weak symbols at load time). Note that we are just adding the
additional explicit instantiations for the `char` specializations, since
the `wchar_t` specializations are not used as often, and as a result there
wouldn't be a clear benefit.

This change is not an ABI break, since we are just adding additional
symbols.

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

show more ...

[libc++] Rework the whole availability markup implementation

Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the header

[libc++] Rework the whole availability markup implementation

Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.

For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.

In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.

Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).

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

show more ...

Open fstream files in O_CLOEXEC mode when possible.

Reviewers: EricWF, mclow.lists, ldionne

Reviewed By: ldionne

Subscribers: smeenai, dexonsmith, christof, ldionne, libcxx-commits

Tags: #libc

D

Open fstream files in O_CLOEXEC mode when possible.

Reviewers: EricWF, mclow.lists, ldionne

Reviewed By: ldionne

Subscribers: smeenai, dexonsmith, christof, ldionne, libcxx-commits

Tags: #libc

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

llvm-svn: 372027

show more ...

[libc++] Set __file_ to 0 in basic_filebuf::close() even if fclose fails

This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() r

[libc++] Set __file_ to 0 in basic_filebuf::close() even if fclose fails

This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
exit status, so __file_ wasn't set to 0. Later when basic_filebuf
destructor ran, we would enter the if (__file_) block again leading to
heap-use-after-free error.

The POSIX specification for fclose says that independently of the return
value, fclose closes the underlying file descriptor and any further
access (including another call to fclose()) to the stream results in
undefined behavior. This is exactly what happened in our test case.

To avoid this issue, we have to always set __file_ to 0 independently of
the fclose return value.

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

llvm-svn: 366730

show more ...

[libc++] Mark <filesystem> tests as failing when the dylib doesn't support filesystem

This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.

This

[libc++] Mark <filesystem> tests as failing when the dylib doesn't support filesystem

This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.

This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.

llvm-svn: 356558

show more ...