Committing on behalf of davidben. Reviewed as D146190
Patch originally by Jan Dörrie in https://reviews.llvm.org/D120064. I've just updated it to include tests, and update documentation that MSVC ABI is not stable.
In the current implementation both `std::optional` and `std::variant` don't perform the EBO on MSVC's ABI. This is because both classes inherit from multiple empty base classes, which breaks the EBO for MSVC. This patch fixes this issue by applying the `empty_bases` declspec attribute, which is already used to fix a similar issue for `std::tuple`.
See https://reviews.llvm.org/D120064 for discussion on MSVC ABI stability. From the discussion, libc++ doesn't have users that expect a stable ABI on MSVC. The fix is thus applied unconditionally to benefit more users. Documentation has been updated to reflect this.
Fixes https://github.com/llvm/llvm-project/issues/61095.
https://github.com/llvm/llvm-project/issues/62396 reports that
GCC 13 barfs on parsing <type_traits> because of the declarations
of `struct __is_convertible`. In GCC 13, `__is_convertible` is a
built-in, but `__is_convertible_to` is not. Clang has both, so
using either should be fine.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D149313
On Windows, the PATH env variable is used for locating dynamically
linked librarys, akin to LD_LIBRARY_PATH on Linux.
The tests that run with a dynamically linked libc++ used "--env
PATH=%{lib}" in the test config. This had the unfortunate side effect
of making other tools from PATH unavailable during the runtime of the
tests; in particular, it caused the "executor-has-no-bash" flag to be
set for all those Windows test configs (with the clang-cl static config
being the only one lacking it).
Thus, this increases the number of tests actually included in the
clang-cl dll and all mingw test configs by 9 tests.
The clang-cl static test configuration has been executing those tests
since the "--env PATH=%{lib}" was removed from that test config in
e78223e79e. (For mingw we haven't had a
need to split the test config between shared and static, which means
that the mingw static test config previously ran with --env PATH
needlessly.)
This increases the test coverage for patches like D146398 which
can't be executed in the executor-has-no-bash configs.
Change the default value of the arg.env to an empty array; when we do
pass values to the option, they get passed as an array of strings,
so make sure the variable behaves consistently when no arguments
have been passed.
Differential Revision: https://reviews.llvm.org/D148324
No test actually does this, but this makes the option behave like
the corresponding one in run.py.
This was broken by commit b8b23aa80e
(https://reviews.llvm.org/D99242) which introduced quoting; instead
of quoting the whole space separated list, quote each individual
argument.
Differential Revision: https://reviews.llvm.org/D149319
In order to use clang-tidy for modules version 17 is required. Some of the
development fixes haven't been backported. This adds the new version to
the CI so it can be used in a follow-up patch.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D148831
The module validation script of D144994 validate whether the contents of
an include match its module. An include is the set of files matching the
pattern:
- foo
- foo/*.
- __fwd/foo.h
Several declarations of the stream headers are in the header iosfwd.
This gives issue using the validation script. Adding iosfwd to the set
of matching files gives too many declarations. For example when
validating the fstream header it will pull in declarations of the
istream header. Instead if writing a set of filters the headers are
granularized into smaller headers containing the expected declarations.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D148927
In D145589, we made the std::bind placeholders inline constexpr to
satisfy C++17. It turns out that this causes ODR violations since the
shared library provides strong definitions for those placeholders, and
the linker on Windows actually complains about this.
Fortunately, C++17 only encourages implementations to use `inline constexpr`,
it doesn't force them. So instead, we unconditionally define the placeholders
as `extern const`, which avoids the ODR violation and is indistinguishable
from `inline constexpr` for most purposes, since the placeholders are
empty types anyway.
Note that we could also go back to the pre-D145589 state of defining them
as non-inline constexpr variables in C++17, however that is definitely
non-conforming since that means the placeholders have different addresses
in different TUs. This is all a bit pedantic, but all in all I feel that
`extern const` provides the best bang for our buck, and I can't really
find any downsides to that solution.
Differential Revision: https://reviews.llvm.org/D149292
algorithm's include of chrono causes include cycles:
```
algorithm -> chrono -> __chrono/convert_to_tm.h -> __chrono/statically_widen.h -> __format/concepts.h -> __format/format_parse_context.h -> string_view -> algorithm
algorithm -> chrono -> __chrono/convert_to_tm.h -> __chrono/statically_widen.h -> __format/concepts.h -> __format/format_parse_context.h -> string_view -> functional -> __functional/boyer_moore_searcher.h -> array -> algorithm
algorithm -> chrono -> __chrono/convert_to_tm.h -> __chrono/statically_widen.h -> __format/concepts.h -> __format/format_parse_context.h -> string_view -> functional -> __functional/boyer_moore_searcher.h -> unordered_map -> algorithm
algorithm -> chrono -> __chrono/convert_to_tm.h -> __chrono/statically_widen.h -> __format/concepts.h -> __format/format_parse_context.h -> string_view -> functional -> __functional/boyer_moore_searcher.h -> vector -> algorithm
```
This is a problem for clang modules after the std mega module is broken up, because it becomes a module cycle which is a hard error.
All of the includes in the `__chrono` and `__format` headers are being used and so can't be removed. algorithm's include of chrono is already removed in C++20, whereas the array, string_view, unordered_map, vector includes of algorithm aren't removed until C++23 (and it's 4x the includes that would need removing). Unconditionally remove the chrono include from algorithm in all versions, so that the module breakup can happen (the module has to apply to all C++ versions).
Reviewed By: Mordante, #libc
Differential Revision: https://reviews.llvm.org/D148405
The removal of operator!= in this header will be done in a separate
commit.
Note in the synopsis of P1614R2 there is a constexpr
template<class BiIter>
constexpr auto operator<=>(const sub_match<BiIter>& lhs, const sub_match<BiIter>& rhs);
In the implementation of P1614R2 there isn't a constexpr
template<class BiIter>
auto operator<=>(const sub_match<BiIter>& lhs, const sub_match<BiIter>& rhs);
There doesn't seem to be an LWG-issue, but it was fixed in the Standard
by removing the constexpr in b050fd474f11441942c88ef69b8622c8036656ac.
Implements part of:
- P1614R2 The Mothership has Landed
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D132310
This patch makes global tag variables like std::allocator_arg
conform to C++17 by defining them as inline constexpr variables.
This is possible without creating an ODR violation now that we don't
define strong definitions of those variables in the shared library
anymore.
Differential Revision: https://reviews.llvm.org/D145589
We don't have `c++` anymore in the Docker image, but the script does
require $CXX to be in the environment so that should always work.
Differential Revision: https://reviews.llvm.org/D148830
We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically it copies the PSTL headers into the libc++ structure.
Reviewed By: ldionne, #libc
Spies: rodgert, mikhail.ramalho, jplehr, bcain, h-vetinari, Mordante, rarutyun, var-const, sstefan1, pcwang-thead, libcxx-commits, arichardson, mgrang, miyuki
Differential Revision: https://reviews.llvm.org/D141779
This is a first step towards granularizing `<locale>`.
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146397
We decided to go a different route. To make the switch easier, rip out the old integration first and build on a clean base.
Reviewed By: ldionne, #libc, #libc_abi
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D148480
As obvious from the paper's title this is an LWG issue and thus retroactively
applied to C++20. This change may the output for certain code points:
1 Considers 8477 extra codepoints as having a width 2 (as of Unicode 15)
(mostly Tangut Ideographs)
2 Change the width of 85 unassigned code points from 2 to 1
3 Change the width of 8 codepoints (in the range U+3248 CIRCLED NUMBER
TEN ON BLACK SQUARE ... U+324F CIRCLED NUMBER EIGHTY ON BLACK
SQUARE) from 2 to 1, because it seems questionable to make an exception
for those without input from Unicode
Note that libc++ already uses Unicode 15, while the Standard requires Unicode 12.
(The last time I checked MSVC STL used Unicode 14.)
So in practice the only notable change is item 3.
Implements
P2675 LWG3780: The Paper
format's width estimation is too approximate and not forward compatible
Benchmark before these changes
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3928 ns 3928 ns 178131
BM_unicode_text<char> 75231 ns 75230 ns 9158
BM_cyrillic_text<char> 59837 ns 59834 ns 11529
BM_japanese_text<char> 39842 ns 39832 ns 17501
BM_emoji_text<char> 3931 ns 3930 ns 177750
BM_ascii_text<wchar_t> 4024 ns 4024 ns 174190
BM_unicode_text<wchar_t> 63756 ns 63751 ns 11136
BM_cyrillic_text<wchar_t> 44639 ns 44638 ns 15597
BM_japanese_text<wchar_t> 34425 ns 34424 ns 20283
BM_emoji_text<wchar_t> 3937 ns 3937 ns 177684
Benchmark after these changes
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3914 ns 3913 ns 178814
BM_unicode_text<char> 70380 ns 70378 ns 9694
BM_cyrillic_text<char> 51889 ns 51877 ns 13488
BM_japanese_text<char> 41707 ns 41705 ns 16723
BM_emoji_text<char> 3908 ns 3907 ns 177912
BM_ascii_text<wchar_t> 3949 ns 3948 ns 177525
BM_unicode_text<wchar_t> 64591 ns 64587 ns 10649
BM_cyrillic_text<wchar_t> 44089 ns 44078 ns 15721
BM_japanese_text<wchar_t> 39369 ns 39367 ns 17779
BM_emoji_text<wchar_t> 3936 ns 3934 ns 177821
Benchmarks without "if(__code_point < (__entries[0] >> 14))"
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3922 ns 3922 ns 178587
BM_unicode_text<char> 94474 ns 94474 ns 7351
BM_cyrillic_text<char> 69202 ns 69200 ns 10157
BM_japanese_text<char> 42735 ns 42692 ns 16382
BM_emoji_text<char> 3920 ns 3919 ns 178704
BM_ascii_text<wchar_t> 3951 ns 3950 ns 177224
BM_unicode_text<wchar_t> 81003 ns 80988 ns 8668
BM_cyrillic_text<wchar_t> 57020 ns 57018 ns 12048
BM_japanese_text<wchar_t> 39695 ns 39687 ns 17582
BM_emoji_text<wchar_t> 3977 ns 3976 ns 176479
This optimization does carry its weight for the Unicode and Cyrillic
test. For the Japanese tests the gains are minor and for emoji it seems
to have no effect.
Reviewed By: ldionne, tahonermann, #libc
Differential Revision: https://reviews.llvm.org/D144499
For the assert.FOO.pass.cpp test, we should be passing _LIBCPP_ENABLE_ASSERTIONS=1
for consistency, even though -D_LIBCPP_ENABLE_ASSERTIONS is equivalent.
For the other test, we shouldn't be forcing assertions to be enabled,
since we already have a CI job that enables assertions by default and
will do the right thing.
Differential Revision: https://reviews.llvm.org/D148736
This patch removes the symbols defined in the library for std::allocator_arg,
std::defer_lock, std::try_to_lock, std::adopt_lock, and std::piecewise_construct.
Those were defined in the library because we provided them in C++03 as an
extension, and in C++03 it was impossible to define them as `constexpr`
variables, like in the spec.
This is technically an ABI break since we are removing symbols from the
library. However, in practice, only programs compiled in C++03 mode who
take the address of those objects (or pass them as a reference) will have
an undefined ref to those symbols. In practice, this is expected to be
rare. First, those are C++11 features that we happen to provide in C++03,
and only the C++03 definition can potentially lead to code referencing
the dylib definition. So any code that is using these objects but compiling
in C++11 mode (as they should) is not at risk. Second, all uses of these
types in the library is done by passing those types by value to a function
that can get inlined. Since they are empty types, the compiler won't
generate an undefined reference if passed by value, since there's nothing
to pass anyway.
Long story short, the risk for code actually containing an undefined
reference to one of these types is rather small (but non-zero). I also
couldn't find any app on the App Store that referenced these symbols,
which supports my impression that this won't be an issue in practice.
Differential Revision: https://reviews.llvm.org/D145587
This patch makes are code less dependant on transitive includes.
This was part of D145800. This patch will be abandoned, but these
changes are still useful. I manually verified declarations of the new
includes are used in these files.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D148645
We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library.
Reviewed By: ldionne, Mordante, #libc
Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai
Differential Revision: https://reviews.llvm.org/D142332
There is no type named sliceExpr, so it's likely a misspelling of
either slice_array or __slice_expr. Neither of which appear to
need the friend declaration.
This may indicate a unimplemented bit of `<valarray`, but ¯\_(ツ)_/¯
Nobody uses it anyway.
(Commit message provided by @EricWF.)
This reverts commit e13c43b229.
The class is never defined. This was discovered while validating modules
in libc++.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D148357
That is already checked later in the function as `__count <= size() - __offset`.
rdar://107884996
Differential Revision: https://reviews.llvm.org/D148030
These test cases were fixed with AIX 73TL1, and are currently passing on AIX machines with that fix. This fix has also been backported to the 7.2 service line. These were tested on a machine with AIX 7.2 TL 5 SP4 installed.
Differential Revision: https://reviews.llvm.org/D148040
When this header now is a fully regular header within the src tree,
give it a more regular name.
Differential Revision: https://reviews.llvm.org/D148072
This header isn't used by any public header, so there shouldn't
be any need to install it or treat it as a heder.
Once it's part of the src subdirectory, I guess one could consider
giving it a more traditional name too.
Differential Revision: https://reviews.llvm.org/D147855
When the libcxx test framework is executed within libunwind, there
are no standard C++ headers available (libunwind builds with
-nostdinc++, but doesn't add any libcxx headers to the include path).
Check that a test that includes <iostream> can be compiled before trying
to build and execute a test program that includes it.
Previously, the compile error here would block all libunwind tests from
executing altogether.
Differential Revision: https://reviews.llvm.org/D147630
