Based on review feedback in #160026.
This makes the substitution a lot more clear now that there is no
documentation around %T.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Verify that the operation passed to resize_and_overwrite returns an
integer-like type, matching the behavior of other standard library
implementations like GCC's libstdc++
Fixes#160577
In the libc++ test suite, we consistently declare main() functions with
full parameters and explicitly return from the function. This helps code
that compiles the tests with -ffreestanding, where main() is not a
special function (with an implicit return and special mangling).
This patch fixes a few stray declarations, including in libunwind and
libc++abi.
Currently, `size_t` and `__libcpp_is_constant_evaluated` are obtained by
transitive inclusion in `<__algorithm/find.h>` when `<cwchar>` is not
included. This broke module build when `_LIBCPP_HAS_WIDE_CHARACTERS` is
`1` and caused CI failure. We should explicitly include the
corresponding internal headers.
Apple dropped support for some older platforms, so we can also remove
the annotations for them.
See https://developer.apple.com/support/xcode/ for the supported
versions.
This fixes spurious failures in
std/input.output/filesystems/fs.op.funcs/fs.op.proximate/proximate.pass.cpp
on Windows.
As part of that test, libcxx tries to open a fake network path such as
"//foo/a". Normally, this sets the error ERROR_BAD_NETPATH, which is
mapped to no_such_file_or_directory. However occasionally, it can end up
setting the error ERROR_NETNAME_DELETED instead.
Map ERROR_NETNAME_DELETED to no_such_file_or_directory just like
ERROR_BAD_NETPATH is mapped. This makes these cases be treated equally
within the create_file_status function in
src/filesystem/file_descriptor.h, causing the __weakly_canonical
function in operations.cpp to keep iterating, rather than erroring out.
There isn't much of a reason to use the allocator abstraction facilities
inside `<any>`. We can improve compile times a bit by avoiding them and
using `__libcpp_{,de}allocate` directly. IMO this also significantly
improves readability here.
Github Actions has got free runners with Windows on ARM64 these days,
which can be used for running CI, just as well as the other existing
cases.
This qualifies this configuration as a supported target platform, thus
add it to the docs in the listing of supported platforms.
When using AppleClang the `clang` feature flag is not set, but the
compiler supports `-flax-vector-conversions=integer`. This adds another
`ADDITIONAL_COMPILE_FLAGS` for AppleClang to fix the CI.
Clang 20 (and early 21 versions; let's hope it can be fixed before the
later versions before such versions become relevant for libcxx CI) have
got an issue with its intrinsics headers, where they use unreserved
names, that users are allowed to override.
See https://github.com/llvm/llvm-project/issues/161808 for the issue
report.
This only crops up in the MSVC build configurations, as recent versions
of some MSVC/UCRT headers include `<intrin.h>`, which ends up pulling in
most intrinsics headers, exposing this issue in the Clang headers.
This should unblock https://github.com/llvm/llvm-project/pull/161736
from being merged.
In the standard, constraint satisfaction checking is done on the
normalized form of a constraint.
Clang instead substitutes on the non-normalized form, which causes us to
report substitution failures in template arguments or concept ids, which
is non-conforming but unavoidable without a parameter mapping
This patch normalizes before satisfaction checking. However, we preserve
concept-id nodes in the normalized form, solely for diagnostics
purposes.
This addresses https://github.com/llvm/llvm-project/issues/61811 and
related concepts conformance bugs, ideally to make the remaining
implementation of concept template parameters easier
Fixes https://github.com/llvm/llvm-project/issues/135190
Fixes https://github.com/llvm/llvm-project/issues/61811
Co-authored-by: Younan Zhang
[zyn7109@gmail.com](mailto:zyn7109@gmail.com)
---------
Co-authored-by: Younan Zhang <zyn7109@gmail.com>
In the standard, constraint satisfaction checking is done on the
normalized form of a constraint.
Clang instead substitutes on the non-normalized form, which causes us to
report substitution failures in template arguments or concept ids, which
is non-conforming but unavoidable without a parameter mapping
This patch normalizes before satisfaction checking. However, we preserve
concept-id nodes in the normalized form, solely for diagnostics
purposes.
This addresses #61811 and related concepts conformance bugs, ideally to
make the remaining implementation of concept template parameters easier
Fixes#135190
Fixes #61811
Co-authored-by: Younan Zhang <zyn7109@gmail.com>
ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS allows waiving asserts, for
cases when we can't count allocations that happen within the libc++
shared library.
When compiling with optimization, it is possible that some calls end up
generated inline, where the overridden operator new/delete do get called
(counting those calls), whereas the compiler may decide to leave some
calls to the external definition (inside the shared library, where we
can't count the calls).
In particular, in one case, a non-optimized build calls
_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev from
the DLL, while it gets inlined (including direct calls to operator
delete) when built with optimization.
Therefore; for the cases where we can't count allocations internally
within the library, waive these asserts.
This fixes all testcases in mingw mode, when built with optimization
enabled.
There is a tradition to use U.S. English spellings for APIs. For
example, it's uninitialized_fill and not uninitialised_fill,
specialization not specialisation, etcetera.
The outer iterator needs to move to the next segment when calling
__compose.
Without this change, `find_segment_if` would never reach the end of the
join_view which caused erroneous result when calling `ranges::find` on a
join_view of bidirectional ranges.
Other specializations using the segmented iterator trait were likely to
be affected as well.
Fixes#158279Fixes#93180
This patch adds a %T substitution directly into the libc++ test format.
This ensures that the libc++ test format will continue to work when we
remove support for %T in llvm lit.
Reviewers: #reviewers-libcxx, ldionne, philnik777
Pull Request: https://github.com/llvm/llvm-project/pull/160026
And add some guaranteed cases (namely, for `expected`, `optional`, and
`variant`) to `is_implicit_lifetime.pass.cpp`.
It's somehow unfortunate that `pair` and `tuple` are not guaranteed to
propagate triviality of copy/move constructors, and MSVC STL fails to do
so due to ABI compatibility. This affects the implicit-lifetime
property.
This has multiple benefits:
1) The compiler has to do way less work to figure out things fold into a
simple `popcount`, improving compile times quite a bit
2) The compiler inlines better, since the compile doesn't have to do
complicated optimizations to get to the same point. Looking at the
pipeline, it seems that without this, LLVM has to go all the way to GVN
to get to the same code as there is after the first InstCombine pass
with this change.
Currently this applies only to `bitset`s with at most 64 bits, but that
is by far the most common case.
#119632 introduced a code size and performance regression. This was
verified by running the included benchmark against trunk and trunk with
#119632 reverted. Instead of actually reverting that patch, we can
inline `__construct_at_end` into the few places it's used instead,
simplifying the implementation further (by not handling special cases we
never actually encounter).
```
Benchmark Baseline Candidate Difference % Difference
------------------------ ---------- ----------- ------------ --------------
BM_vector_bool_size_ctor 29.91 8.56 -21.35 -71.37
```
Previously, we would report a successful run if the benchmark exited
with an error, and we would produce a timing for the benchmark. After
this patch, we consider an error in the benchmark to be a failed LIT
test and we don't produce any benchmark data for it.
