std::bind is supposed to be constexpr-friendly since C++20 and it was
marked as such in our synopsis. However, the tests were not actually
testing any of it and as it happens, std::bind was not really constexpr
friendly. This fixes the issue and makes sure that at least some of the
tests are running in constexpr mode.
Some tests for std::bind check functions that return void, and those
use global variables. These tests haven't been made constexpr-friendly,
however the coverage added by this patch should be sufficient to get
decent confidence.
Differential Revision: https://reviews.llvm.org/D149295
Some configurations flags are always the same. We can just remove them to make the code a bit cleaner.
Reviewed By: ldionne, #libc
Spies: pcwang-thead, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D149502
This is an attempt to reduce the insane amount of network we use when
uploading Clang binaries to Buildkite for other jobs to use. We think
that removing debug information will result in much smaller binaries.
This was discovered while working on modules. They can't export
declarations with internal linkage.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D149593
This is done by removing configurations we don't support.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D149499
When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and so makes an empty declaration for ::mbstate_t. That conflicts with the declarations in __mbstate_t.h and cwchar since both of those headers do get mbstate_t before making ::mbstate_t.
Change `__mbstate_t.h` to just get the underlying declaration for mbstate_t and not make a declaration for ::mbstate_t. Include __mbstate_t.h in uchar.h and wchar.h when their next headers aren't available so that at least mbstate_t gets defined.
Add __std_mbstate_t.h to declare ::mbstate_t for headers that need that when cuchar or cwchar aren't available (because either _LIBCPP_HAS_NO_WIDE_CHARACTERS or _LIBCPP_CXX03_LANG).
Reviewed By: ldionne, Mordante, #libc, philnik
Differential Revision: https://reviews.llvm.org/D148542
During the review of D140653 it was suggested to use vector in
__retarget_buffer instead of manually managing the memory. Due to the
requirements of the Standard it turns out format needs to include vector
leading to a cycle. Therefore switching back to manual memory
management.
This is a preparation to fix https://llvm.org/PR61314
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D148826
__use() can't be marked as constexpr in C++11 because it returns void,
which is not a literal type. But it turns out that we just don't need
to define it at all, since it's never called outside of decltype.
Differential Revision: https://reviews.llvm.org/D149360
This patch makes std::pair's constructors and assignment operators
closer to conforming in C++23. The only missing bit I am aware of
now is `reference_constructs_from_temporary_v` checks, which we
don't have the tools for yet.
This patch also refactors a long-standing non-standard extension where
we'd provide constructors for tuple-like types in all standard modes. The
criteria for being a tuple-like type are different from pair-like types
as introduced recently in the standard, leading to a lot of complexity
when trying to implement recent papers that touch the pair constructors.
After this patch, the pre-C++23 extension is provided in a self-contained
block so that we can easily deprecate and eventually remove the extension
in future releases.
Differential Revision: https://reviews.llvm.org/D143914
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
The __cpp_lib_format_ranges feature-test macro only depends on P2286R8
and P2585R0. Note since LWG3750 only affects these two C++23 papers
there is nothing to do for older language versions.
(The __cpp_lib_format feature-test macro depends on the incomplete
formatting for chrono. So this part can't be marked as complete yet.)
This completes
- P2286R8 Formatting ranges
- P2585R0 Improving default container formatting
This partly implements
- LWG3750 Too many papers bump __cpp_lib_format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D147880
This is based on the last open review comment in D144331 and is applied
to all occurrences.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D147885
D144994 adds modules to libc++. In order to test them some newer and
additional tools are required.
CMake 3.26
This is in combination with Clang 16 or newer makes it possible to
conveniently build modules with CMake. Unfortunately CMake 3.26 in our
setup has an issue with unused linker flags. This causes libunwind not
to compile at all. D145596 contains a quick-fix which is in the module
patch. The patch D142957 and followups will contain a proper fix.
Therefore install CMake 3.26 in a separate location, allowing to test
the module patch in the CI.
Ninja 1.11
Building modules requires dynamic rules, which requires this version.
This is a CMake 3.26 requirement to use modules. Note that without using
modules CMake still accepts older Ninja versions.
clang-scan-deps (in the tools package)
This tool is used by CMake to get the module dependencies. Note
strictly this currently will only be used for Clang 16 and Clang 17.
Clang 15 and Clang 14 are not needed. They are installed to keep
updating to Clang 18 and later easier.
(In the future we might not test modular build with all Clang versions,
however at the moment the feature is still in development in both Clang
and libc++ so it would be good to detect regressions.)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146822
This file was added before we started granularizing the headers, but is essentially just a granularized header. This moves the header to the correct place.
Reviewed By: #libc, EricWF
Spies: libcxx-commits, arichardson, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146395
This omission seems to be there for a long time, it's in the initial
libc++ import. This was discovered while working on the std modules.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D147850
LWG3720 Restrict the valid types of arg-id for width and precision in
std-format-spec
Depends on D144325
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144326
We changed the `abort` calls when trying to throw exceptions in `-fno-exceptions` mode to `__verbose_abort` calls, which removes the dependency in most files.
Reviewed By: ldionne, #libc
Spies: dim, emaste, mikhail.ramalho, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D146076
This cuts the time it takes to run the test in half.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D147320
Since stacktrace header is WIP and it's not sure that will be done
before LLVM17 update the documentation. When the header is implemented
implementing the formatter is trivial, so that can be done quickly
afterwards.
Implements parts of:
- P2693R1 Formatting thread::id and stacktrace
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144331
This LWG issue is based on the discussion regarding
P2733R3 Fix handling of empty specifiers in std::format
This paper was disussed and changed a few times in LEWG during the
Issaquah meeting. The paper was not voted in, instead LEWG asked for
a DR against C++26.
This LWG issue contains the direction voted by LEWG. This issue has not
been voted in yet. However it fixes some of the defencies on the
container based formatting. Without this fix the range-default-formatter
for strings looks bad when used in containers.
The changes of this issue match the intended changes of P27333.
type fmt before after (if changed)
---------------------------------------------------------------
char {} a
char {:?} 'a'
array<char, 1> {} ['a']
array<char, 1> {::} [a]
array<char, 1> {::c} [a]
array<char, 1> {::?} ['a']
map<char, char> {} {a: a} -> {'a': 'a'}
map<char, char> {::} {'a': 'a'}
set<char> {} {'a'}
set<char> {::} {a}
set<char> {::c} {a}
set<char> {::?} {'a'}
tuple<char> {} ('a')
stack<char> {} ['a']
stack<char> {::} [a]
stack<char> {::c} [a]
stack<char> {::?} ['a']
array<array<char, 1>, 1> {} [[a]] -> {'a': 'a'}
array<array<char, 1>, 1> {::} [['a']]
array<array<char, 1>, 1> {:::} [[a]]
array<array<char, 1>, 1> {:::c} [[a]]
array<array<char, 1>, 1> {:::?} [['a']]
array<tuple<char>, 1> {} [(a)] -> [('a')]
tuple<tuple<char>> {} ((a)) -> (('a'))
tuple<array<char, 1>> {} ([a]) -> (['a'])
Note the optimization text as mentioned in the tuple formatter can't be
done. The call to parse may affect the formatter so its state needs to
be preserved.
Reviewed By: ldionne, #libc, EricWF
Differential Revision: https://reviews.llvm.org/D145847
This adds a list of attributes which can be pretty to be able to reject attributes which were introduced in a later C++ standard.
Fixes#61196
Reviewed By: Mordante, #libc
Spies: mikhail.ramalho, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145508
These changes make it possible to use __synth_three_way in modules. The
change from a lambda to a function is a Clang issue.
The change is list was needed since the compiler couldn't deduce the
comparison template argument.
Adds a few missing includes too.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146545
LWG3842 Unclear wording for precision in chrono-format-spec
Note there is nothing to do, the issue clarifies the wording in the Standard.
The new wording matches my interpretation of the previous wording and this has
already been implemented in libc++.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144328
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?intmax_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146821
Previously, we inconsistently defined whether a feature was unavailable
on a given deployment target. We would have availability attributes for
all features, but only some features had the equivalent of a _HAS_NO_FOO
macro in the form of the DISABLE_FTM___foo macros. Instead, systematically
define a _HAS_NO_FOO macro, which makes it easier to understand how to
add availability markup for a new platform.
Differential Revision: https://reviews.llvm.org/D147226
The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).
This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.
Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.
Differential Revision: https://reviews.llvm.org/D146366
The __insertion_sort_move helper function is only used in partial_sort.h,
so it makes sense to define it there.
Differential Revision: https://reviews.llvm.org/D147080
The helper is mis-named, since it won't work as-is on ordered containers
like set and map, because they rely on being able to store keys that are
partial_ordering::unordered, and that's UB for an ordered container.
This was most likely a typo or an unintended naming mistake, since
the function is only used with sequence containers anyway.
Differential Revision: https://reviews.llvm.org/D146991
AppleClang 1403 has some bugs that prevent std::source_location from
working properly on it. Consequently, we XFAILed the unit test for
source_location with that compiler. However, we should also avoid
advertising that the feature is supported on that compiler, otherwise
our feature-test macros lie. This was noticed to break Boost.Asio
when building with a recent libc++ and AppleClang 14.0.3.
rdar://106863087
Differential Revision: https://reviews.llvm.org/D146837
Sometimes, a target can look like `<arch>-apple-macosx10.15.0` instead
of `<arch>-apple-macosx10.15`. This ensures that the test suite handles
those target triples properly as well.
Differential Revision: https://reviews.llvm.org/D146365
Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit features like
`availability-shared_mutex-missing` to represent those. This makes the
XFAIL annotations leaner, and solves the problem of XFAIL comments
potentially getting out of sync. This would also make it easier for
another vendor to add their own annotations to the test suite by simply
changing how the feature is defined for their OS releases, instead
of having to modify hundreds of tests to add repetitive annotations.
This doesn't touch *all* annotations -- only annotations that were widely
duplicated are given named features (e.g. when filesystem or shared_mutex
were introduced). I still think it probably doesn't make sense to have a
named feature for every single fix we make to the dylib.
This is in essence a revert of 2659663, but since then the test suite
has changed significantly. Back when I did 2659663, the configuration
files we have for the test suite right now were being bootstrapped and
it wasn't clear how to provide these features for back-deployment in
that context. Since then, we have a streamlined way of defining these
features in `features.py` and that doesn't impact the ability for a
configuration file to stay minimal.
The original motivation for this change was that I am about to propose
a change that would touch essentially all XFAIL annotations for back-deployment
in the test suite, and this greatly reduces the number of lines changed
by that upcoming change, in addition to making the test suite generally
better.
Differential Revision: https://reviews.llvm.org/D146359
Those seem to have been failing for a while but we might not have noticed
because of the recent CI instability issues. I'm marking them as unsupported
to try to get the CI functional again, especially since the majority of
<format> tests are already not working on GCC 12.
Building with -DLIBCXX_ENABLE_THREADS=OFF -DLIBCXXABI_ENABLE_THREADS=OFF
(like e.g. for wasm) fails after D146228 because of a misplaced std
namespace begin/end.
Reviewed By: philnik, #libc
Differential Revision: https://reviews.llvm.org/D146682
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?intptr_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146643
std::format is currently experimental, so there is technically no
deployment target requirement for it (since the only symbols required
for it are in `libc++experimental.a`).
However, some parts of std::format depend indirectly on the floating
point std::to_chars implementation, which does have deployment target
requirements.
This patch removes all the availability format for std::format and
updates the XFAILs in the tests to properly explain why they fail
on old deployment targets, when they do. It also changes a couple
of tests to avoid depending on floating-point std::to_chars when
it isn't fundamental to the test.
Finally, some tests are marked as XFAIL but I added a comment saying
TODO FMT This test should not require std::to_chars(floating-point)
These tests do not fundamentally depend on floating-point std::to_chars,
however they end up failing because calling std::format even without a
floating-point argument to format will end up requiring floating-point
std::to_chars. I believe this is an implementation artifact that could
be avoided in all cases where we know the format string at compile-time.
In the tests, I added the TODO comment only to the places where we could
do better and actually avoid relying on floating-point std::to_chars
because we know the format string at compile-time.
Differential Revision: https://reviews.llvm.org/D134598
This also updates the moved code to the current style. (i.e. `_VSTD` -> `std`, `_LIBCPP_INLINE_VISIBILITY` -> `_LIBCPP_HIDE_FROM_ABI`, clang-format).
Reviewed By: Mordante, #libc, EricWF
Spies: arichardson, libcxx-commits, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146228
This has been done using the following commands
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)ptrdiff_t)|\1std::\2|' \{} \;
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)max_align_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.,
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146550
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
The `std` module doesn't export `::size_t`, this is a preparation for that module.
Reviewed By: ldionne, #libc, EricWF, philnik
Differential Revision: https://reviews.llvm.org/D146088
Internal linkages fails when building libc++ with modules. Using
internal linkage is headers seems questionable to change the linkage.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D146384
This allows the compiler to inline the constructors.
Reviewed By: ldionne, #libc
Spies: mikhail.ramalho, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144580
As explained in the release note, libc++ used to provide various
global variables as an extension in C++03 mode. Unfortunately, that
made our definition non-conforming in all standard modes. This was
never a big problem until recently, since we are trying to support
C++20 Modules in libc++, and that requires cleaning up the definition
of these variables.
This change is the first in a series of changes to achieve our end goal.
This patch removes the ability for users to rely on the (incorrect)
definition of those global variables inside the shared library. The
plan is to then remove those definitions from the shared library
(which is an ABI break but I don't think it will have impact), and
finally to make our definition of those variables conforming in all
standard modes.
Differential Revision: https://reviews.llvm.org/D145422
This changes all `__enable_if`s inside `<string>` to a common pattern. Specifically, it's always inside the `template <>` and uses the `, int> = 0` style.
Reviewed By: ldionne, #libc
Spies: mikhail.ramalho, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144568
The original `__dynamic_cast` implementation does not use the ABI-provided `src2dst_offset` parameter which helps improve performance on the hot paths. This patch improves the performance on the hot paths in `__dynamic_cast` by leveraging hints provided by the `src2dst_offset` parameter. This patch also includes a performance benchmark suite for the `__dynamic_cast` implementation.
Reviewed By: philnik, ldionne, #libc, #libc_abi, avogelsgesang
Spies: mikhail.ramalho, avogelsgesang, xingxue, libcxx-commits
Differential Revision: https://reviews.llvm.org/D138005
We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.
As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.
Differential Revision: https://reviews.llvm.org/D146236
This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind.
Reviewed By: ldionne, #libunwind, #libc, #libc_abi
Spies: mikhail.ramalho, phosek, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144252
Having the header granularized makes it possible to remove the
dependency on this header in <format>. This <format> header gets
included in more headers due to more usage of std::formatter in the
library. This should reduce the number of transitive includes.
Note formatting the new headers will be done in a followup patch.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D145590
Implements parts of P1614R2: `operator<=>` for `map` and `multimap`
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D145976
This results in proper error messages instead of just an abort.
Reviewed By: ldionne, Mordante, #libc
Spies: #libc_vendors, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D141222
While implementing the tests for LWG3720 I noticed the std::format
errors for non-formattable types are not user friendly (and thus hard to
write a .verify test too).
The issue stems from using a deleted function for invalid types. By
using a function that returns an invalid value the diagnostics become a
lot better. Before this change the existing "invalid value"
static_assert could never trigger. Now it can be triggered by user
code, therefore a diagnostic message has been added.
Before this change using a non-formattable type resulted in list of
error messages along the line of
.../include/c++/v1/__format/format_arg_store.h:167:29: error: call to deleted function '__determine_arg_t'
constexpr __arg_t __arg = __determine_arg_t<_Context, remove_cvref_t<_Tp>>();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../include/c++/v1/__format/format_arg_store.h:210:54: note: in instantiation of function template specialization 'std::__format::__create_format_arg<std::format_context, char16_t &>' requested here
basic_format_arg<_Context> __arg = __format::__create_format_arg<_Context>(__args);
^
.../include/c++/v1/__format/format_arg_store.h:246:19: note: in instantiation of function template specialization 'std::__format::__create_packed_storage<std::format_context, int &, char16_t &>' requested here
__format::__create_packed_storage(__storage.__types_, __storage.__values_, __args...);
^
.../include/c++/v1/__format/format_functions.h:73:10: note: in instantiation of member function 'std::__format_arg_store<std::format_context, int &, char16_t &>::__format_arg_store' requested here
return _VSTD::__format_arg_store<_Context, _Args...>(__args...);
^
.../include/c++/v1/__config:664:17: note: expanded from macro '_VSTD'
# define _VSTD std
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:46:50: note: in instantiation of function template specialization 'std::make_format_args<std::format_context, int &, char16_t &>' requested here
TEST_IGNORE_NODISCARD std::vformat(fmt, std::make_format_args<context_t<CharT>>(args...));
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:69:3: note: in instantiation of function template specialization 'test_exception<char, int, char16_t>' requested here
test_exception(SV("{:{}}"), 42, u'0');
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:97:3: note: in instantiation of function template specialization 'test<char>' requested here
test<char>();
^
.../include/c++/v1/__format/format_arg_store.h:154:19: note: candidate function [with _Context = std::format_context, _Tp = char16_t] has been explicitly deleted
consteval __arg_t __determine_arg_t()
^
.../include/c++/v1/__format/format_arg_store.h:148:19: note: candidate function [with _Context = std::format_context, _Tp = char16_t]
consteval __arg_t __determine_arg_t() {
<more errors omitted>
.../include/c++/v1/__format/format_arg_store.h:185:22: note: initializer of '__arg' is not a constant expression
.../include/c++/v1/__format/format_arg_store.h:167:21: note: declared here
constexpr __arg_t __arg = __determine_arg_t<_Context, remove_cvref_t<_Tp>>();
^
.../build/include/c++/v1/__format/format_arg_store.h:194:73: error: member reference base type 'char16_t' is not a structure or union
__arg, basic_string_view<typename _Context::char_type>{__value.data(), __value.size()}};
~~~~~~~^~~~~
11 errors generated.
After the change using the same non-formmatable type gives the following
diagnostics
.../include/c++/v1/__format/format_arg_store.h:168:3: error: static assertion failed due to requirement '__arg != __arg_t::__none': the supplied type is not formattable
static_assert(__arg != __arg_t::__none, "the supplied type is not formattable");
^ ~~~~~~~~~~~~~~~~~~~~~~~~
.../include/c++/v1/__format/format_arg_store.h:210:54: note: in instantiation of function template specialization 'std::__format::__create_format_arg<std::format_context, char16_t &>' requested here
basic_format_arg<_Context> __arg = __format::__create_format_arg<_Context>(__args);
^
.../include/c++/v1/__format/format_arg_store.h:246:19: note: in instantiation of function template specialization 'std::__format::__create_packed_storage<std::format_context, int &, char16_t &>' requested here
__format::__create_packed_storage(__storage.__types_, __storage.__values_, __args...);
^
.../include/c++/v1/__format/format_functions.h:73:10: note: in instantiation of member function 'std::__format_arg_store<std::format_context, int &, char16_t &>::__format_arg_store' requested here
return _VSTD::__format_arg_store<_Context, _Args...>(__args...);
^
.../include/c++/v1/__config:664:17: note: expanded from macro '_VSTD'
# define _VSTD std
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:46:50: note: in instantiation of function template specialization 'std::make_format_args<std::format_context, int &, char16_t &>' requested here
TEST_IGNORE_NODISCARD std::vformat(fmt, std::make_format_args<context_t<CharT>>(args...));
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:69:3: note: in instantiation of function template specialization 'test_exception<char, int, char16_t>' requested here
test_exception(SV("{:{}}"), 42, u'0');
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:97:3: note: in instantiation of function template specialization 'test<char>' requested here
test<char>();
^
.../include/c++/v1/__format/format_arg_store.h:168:23: note: expression evaluates to '0 != 0'
static_assert(__arg != __arg_t::__none, "the supplied type is not formattable");
~~~~~~^~~~~~~~~~~~~~~~~~
1 error generated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144325
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?int(_[a-z]+)?[0-9]{1,2}_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145880
This patch also updates the moved code to the new style (i.e. formatted, replaced marcos and typedefs)
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145095
Don't forward to `min_element` for small types that are trivially copyable, and instead use a naive loop that keeps track of the smallest element (as opposed to an iterator to the smallest element). This allows the compiler to vectorize the loop in some cases.
Reviewed By: #libc, ldionne
Spies: ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D143596
This one is easy -- Clang supports rvalue references in C++03 mode, so
we should be able to remove that conditional.
As a fly-by fix, turn a few static_casts to std::forward.
Differential Revision: https://reviews.llvm.org/D145701
This patch bumps the minimum macOS version for building the dylib
or back-deploying a statically-linked libc++ from macOS 10.11 to
macOS 10.13. AFAICT, Chrome was the last one to require macOS 10.11,
but since then they have bumped their minimal supported version to
macOS 10.13.
Differential Revision: https://reviews.llvm.org/D145012
It was only used in one place, and it seems entirely valid to use
constexpr unconditionally in that location.
Note that a different change was attempted, i.e. using consteval
unconditionally. However, this led to http://llvm.org/PR60709.
Differential Revision: https://reviews.llvm.org/D145700
After commit 0a4aa8a122 we see failures
like:
optional:722:7: error: missing '#include <__type_traits/conjunction.h>';
'_And' must be declared before it is used
and:
optional:683:46: error: missing '#include
<__type_traits/disjunction.h>'; '_Or' must be declared before it is used
using __check_constructible_from_opt = _Or<
Adding these here fixes that.
I'm not familiar with the libcxx codebase, will ask the author to take a
look too.
This revision adds:
- New test allocator, which cleans memory during allocation and deallocation,
- tests using that allocator to vector.
This patch is part of our efforts to add support for ASan annotations with every
allocator.
This commit adds a new allocator for testing purposes only. The safe allocator
ensures that memory is cleand (zeroed) during allocation and deallocation, and
is intendted to test ASan annotations for every allocator in std::vector.
Check: D136765
Those tests should work correctly, even if support for every allocator in std::vector
is not yet available.
Support in ASan API was added here: rGdd1b7b797a116eed588fd752fbe61d34deeb24e4
Reviewed By: philnik, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D145597
During the implementation of P2286 a second Unicode decoder was added.
The original decoder was only used for the width estimation. Changing
an ill-formed Unicode sequence to the replacement character, works
properly for this use case. For P2286 an ill-formed Unicode sequence
needs to be formatted as a sequence of code units. The exact wording in
the Standard as a bit unclear and there was odd example in the WP. This
made it hard to use the same decoder. SG16 determined the odd example in
the WP was a bug and this has been fixed in the WP.
This made it possible to combine the two decoders. The P2286 decoder
kept track of the size of the ill-formed sequence. However this was not
needed since the output algorithm needs to keep track of size of a
well-formed and an ill-formed sequence. So this feature has been
removed.
The error status remains since it's needed for P2286, the grapheme
clustering can ignore this unneeded value. (In general, grapheme
clustering is only has specified behaviour for Unicode. When the string
is in a non-Unicode encoding there are no requirements. Ill-formed
Unicode is a non-Unicode encoding. Still libc++ does a best effort
estimation.)
There UTF-8 decoder accepted several ill-formed sequences:
- Values in the surrogate range U+D800..U+DFFF.
- Values encoded in more code units than required, for example 0+0020
in theory can be encoded using 1, 2, 3, or 4 were accepted. This is
not allowed by the Unicode Standard.
- Values larger than U+10FFFF were not always rejected.
Reviewed By: #libc, ldionne, tahonermann, Mordante
Differential Revision: https://reviews.llvm.org/D144346
The AIX linker does not support linking against libc++ if it exports symbols are redefined within compiled code.
Differential Revision: https://reviews.llvm.org/D140675
Clang wants to enable this flag by default, but libc++ isn't working with it yet.
Reviewed By: Mordante, #libc, #libc_abi, EricWF
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D144667
The module std does not provide c-types in the global namespace. This
means all these types need to be fully qualified. This is a first step
to convert them by using sed.
Since this is an automated conversion other types like uint64_t are kept
as is.
Note that tests in the directory libcxx/test/std/depr/depr.c.headers
should not be converted automatically. This requires manual attention,
there some test require testing uint32_t in the global namespace. These
test should fail when using the std module, and pass when using the
std.compat module.
A similar issue occurs with atomic, atomic_uint32_t is specified as
using atomic_uint32_t = atomic<uint32_t>; // freestanding
So here too we need to keep the name in the global namespace in the
tests.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145520
This check flags code which uses `_LIBCPP_STD_VER` the wrong way, or tries to use `__cplusplus`. It flags cases where we use `_LIBCPP_STD_VER >` instead of `_LIBCPP_STD_VER >=` and where wrong values are used (e.g. `_LIBCPP_STD_VER >= 24`).
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D144261
LWG3358 §[span.cons] is mistaken that to_address can throw
Since last - first has to throw tests are added to make sure this always
happens.
Depends on D142808
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142843
LWG3839 range_formatter's set_separator, set_brackets, and
underlying functions should be noexcept
Adds tests for:
template<ranges::input_range R, class charT>
struct range-default-formatter<range_format::sequence, R, charT>
These were missing, the format functions tests for the sequences
are already present.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144286
Avoids using operator& in basic_string since an evil char-like type can
hijack this operator. Added some more evil operators, this found a place
where equality was compared directly and not via the traits.
This adds a helper test string. This is now only used in a few tests,
but the intention is to use this in more tests for basic_string.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D145257
The m type in a range formatter may only be used when a pair or a tuple
with two elements is used. This was not correctly validated as reported
in llvm.org/PR60995.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145309
Fixes llvm.org/PR58714 reported by @jwakely and a similar issue
reported privately by @vitaut.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145306
This provides a single place for downstream to customize (or turn off)
printing information to stderr within the test suite.
Differential Revision: https://reviews.llvm.org/D145405
https://wg21.link/LWG2444 updated the comparison complexity of
std:sort_heap to be at most 2N log (N) where N == last - first. In the
current implementation, we invoke __pop_heap exactly N-1 times. In each
call to __pop_heap, we first go down the heap from first to possibly
last in the function __floyd_sift_down. Then, we possibly go back up in
the function __sift_up.
In the function __floyd_sift_down, there is loop in which one comparison
is made in each iteration. The loop runs till __child becomes greater
than (__len - 2) / 2. __child starts at 0 and it is at least set to 2 *
__child + 1 on each iteration. Thus, after k iterations, __child will
be at least 2^k - 1. After log(N) iterations, __child >= 2^(log(N)) -
1 = N - 1 > (__len - 2) / 2. This means that the while loop in the
function __floyd_sift_down would perform at most log(N) comparisons on
each invocation.
In the function __sift_up, there is one comparison made that will almost
always occur. After that there is a do-while loop. The comparison
function is invoked once in each iteration. In the worst case, the loop
will run till __len goes down to zero. It can start from (N-3)/2. In
each iteration, __len goes down to (__len-1) / 2. After k iterations,
__len will be at most (N - 2^(k+1) -1) / 2^(k+1). Thus, __len will
become when (N-2^(k+1)-1) < 2^(k+1) i.e. N < 2^(k+2) + 1. This means
at most log(N) - 1 iterations for the loop. So in total at most log(N)
comparison will be performed in __sift_up.
So overall for each iteration of the loop in __pop_heap, there will at
most 2 log(N) comparisons. So, the total number of comparisons is
at most 2 N log(N).
We also updated the test sort.heap/complexity.pass.cpp to test for the
number of operations.
Differential Revision: https://reviews.llvm.org/D144538
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8.
Formatting a const qualified vector<bool> fails to work on libc++. This
is due to our non-conforming type for vector<bool>::const_reference. The
type is a __bit_const_reference<vector> instead of a bool. (This is
fixed in ABI v2.)
This fixes this formatter and enables the test written for it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144279
LWG3103 Errors in taking subview of span should be ill-formed where possible
Note that the real work was already done before, including tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D143432
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
Currently, there are bugs in Clang's intrinsics for type traits when
handling Objective-C++ `id` (e.g. in `add_pointer`). As a temporary
workaround, don't use these intrinsics in the Objective-C++ mode.
Differential Revision: https://reviews.llvm.org/D145186
