This fixes clang warnings (that are treated as errors when running
the test suite):
libcxx/include/string:4409:59: error: definition of dllimport static field [-Werror,-Wdllimport-static-field-def]
basic_string<_CharT, _Traits, _Allocator>::npos;
The warning is normally not visible as long as the libc++ headers
are treated as system headers.
The same construct is always an error in MSVC.
(One _LIBCPP_FUNC_VIS was added in
2d8f23f571, which broke DLL builds.
59919c4d6b fixed this by adding another
_LIBCPP_FUNC_VIS on the declaration for consistency, but the underlying
issue remained, that one can't use dllimport here.)
Differential Revision: https://reviews.llvm.org/D97168
Implements parts of:
- P0645 Text Formatting
Depends on D92214
Reland with changes:
The format header will only be compiled if the compiler used has support
for concepts. This should fix the issues with the initial version.
Differential Revision: https://reviews.llvm.org/D93166
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.
31e820378b 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
Contrary to the current visibility macro documentation, it appears that
gcc does handle visibility attribute on extern templates correctly, e.g.
https://godbolt.org/g/EejuV7. We need this so that extern template
instantiations of classes not marked _LIBCPP_TEMPLATE_VIS (e.g.
__vector_base_common) are correctly exported with gcc when building with
hidden visibility.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D35388
* The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9).
* Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b).
That's a preparation step to add c++2b support to libc++.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93383
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
This is a re-commit. The previous commit was reverted because it exposed
a pre-existing bug that has since been fixed / worked around; see
PR48434.
Differential Revision: https://reviews.llvm.org/D91311
This change exposed a pre-existing issue with deserialization cycles
caused by a combination of attributes and template instantiations
violating the deserialization ordering restrictions; see PR48434 for
details.
A previous commit attempted to work around PR48434, but appears to have
only been a partial fix, and fixing this properly seems non-trivial.
Backing out for now to unblock things.
This reverts commit 98f76adf4e and
commit a64c26a47a.
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
Differential Revision: https://reviews.llvm.org/D91311
This is the the minimal change introduced in [[ https://reviews.llvm.org/D88599 | D88599 ]] to unblock the controversial change and discussion of proper separation between thread from thread id which will continue in D88599.
This patch will address the differences of definition of pthread_t on z/OS vs. Linux and other OS. Main trick to make the code work on z/OS relies on redefining libcpp_thread_id type and _LIBCPP_NULL_THREAD macro. This is necessary to separate initialization of libcxx_thread_id from the one of __libcxx_thread_t;
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91875
This implements the std::filesystem parts of P0482 (which is already
marked as in progress), and applies the actions that are suggested
in P1423.
Differential Revision: https://reviews.llvm.org/D90222
Zoe Carver says: "We decided that libc++ only supports C++20 constexpr algorithms
when `is_constant_evaluated` is also supported. Here's a link to the discussion."
https://reviews.llvm.org/D65721#inline-735682
Remove _LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED from tests, too.
See Louis's 5911e6a885 if needed to fix bots.
I've applied `UNSUPPORTED: clang-8` preemptively to the altered tests;
I don't know for sure that this was needed, because no clang-8 buildbots
are triggered on pull requests.
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
This commit makes it clear that the typeinfo comparison implementation
is automatically selected by default, and that the CMake option only
overrides the value. This has been a source of confusion and bugs ever
since we've introduced complexity in that area, so I'm trying to simplify
it while still allowing for some control on the implementation.
Differential Revision: https://reviews.llvm.org/D91574
Erroring out prevents the library from working with other file formats
(e.g. in embedded). Since that error does not guard us from doing something
incorrect, it seems fine to just remove it.
The unavailability of posix_memalign on z/OS forces us to define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION'. The use of posix_memalign is being used in libcxx/src/new.cpp.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D90178
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
The aim of this patch is to enable POSIX _l functions for z/OS. In particular, the functions are provided with libc++ and this patch resorts to the fallback functions. Nonetheless, the functions are being added so the implementation of the ctype<> member functions can call them. The following changes were needed to allow for a successful build when using the libc++ library for z/OS.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D90319
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
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
On old Apple platforms (pre 10.9), we couldn't rely on the iostreams
explicit instantiations being part of the dylib. However, we don't
support back-deploying to such old deployment targets anymore, so the
workaround can be dropped.
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
Due to the need to support compilers that implement builtin operator
new/delete but not their align_val_t overloaded versions, there was a
lot of complexity. By assuming that a compiler that supports the builtin
new/delete operators also supports their align_val_t overloads, the code
can be simplified quite a bit.
Differential Revision: https://reviews.llvm.org/D88301
The debug mode always had three possibilities:
- _LIBCPP_DEBUG is undefined => no assertions
- _LIBCPP_DEBUG == 0 => some assertions
- _LIBCPP_DEBUG == 1 => some assertions + iterator checks
This was documented that way, however the code did not make this clear
at all. The discrepancy between _LIBCPP_DEBUG and _LIBCPP_DEBUG_LEVEL
was especially confusing. I reworked how the various macros are defined
without changing anything else to make the code clearer.
This seems to have been added a long time ago as a temporary help
for debugging some <regex> issue, but it's really the same as
_LIBCPP_EXTERN_TEMPLATE.
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
We don't support GCC in C++03 mode, and Clang provides variadic templates
even in C++03 mode. So there's effectively no supported compiler that
doesn't support variadic templates.
This effectively gets rid of all uses of _LIBCPP_HAS_NO_VARIADICS, but
some workarounds for the lack of variadics remain.
D56913 introduced the _LIBCPP_FREESTANDING macro and guarded its
definition by:
#ifndef __STDC_HOSTED__
# define _LIBCPP_FREESTANDING
#endif
However, __STDC_HOSTED__ is defined as 0 in freestanding implementations
instead of undefined, which means that _LIBCPP_FREESTANDING would never
get defined. This patch corrects the above as:
#if __STDC_HOSTED__ == 0
# define _LIBCPP_FREESTANDING
#endif
Differential Revision: https://reviews.llvm.org/D86055
This reverts commit 99f3b231cb. It breaks
libcxx/modules/stds_include.sh.cpp on macOS as the new include to sys/cdefs.h
causes a dependency from __config to the Darwin module (which already has
a dependency on __config). This cyclic dependency breaks compiling the std
module which breaks compiling pretty much every program with ToT libc++ and
enabled modules.
I'll revert for now to get the bots green again. Sorry for the inconvenience.
timespec_get is not available in Apple SDKs when (__DARWIN_C_LEVEL >= __DARWIN_C_FULL)
isn't true, which leads to libc++ trying to import ::timespec_get into
namespace std when it's not available. This issue has been reported to
Apple's libc, but we need a workaround in the meantime.
https://llvm.org/PR47208
rdar://68157284
We don't support GCC in C++03 mode, and Clang provides rvalue references
even in C++03 mode. So there's effectively no supported compiler that
doesn't support rvalue references.
Differential Revision: https://reviews.llvm.org/D84943
First, add a TEST_HAS_QUICK_EXIT macro to mirror other C11 features like
TEST_HAS_ALIGNED_ALLOC, and update the tests for that.
Second, get rid of TEST_HAS_C11_FEATURES and _LIBCPP_HAS_C11_FEATURES,
which were only used to ensure that feature macros don't get out of
sync between <__config> and "test_macros.h". This is not necessary
anymore, since we have tests for each individual macro now.
Instead of detecting it automatically but also allowing for the setting
to be specified explicitly, always detect whether exceptions are enabled
based on whether -fno-rtti (or equivalent) is used. It's less confusing
to have a single way of tweaking that knob.
This change follows the lead of 71d88cebfb.
Martin Storsjö