MS UCRT seems confused on the status of LWG1327, and still provides
pre-LWG1327 overload set the related math functions, which can't handle
integer types as required. It is probably that UCRT won't fixed this in
a near future, per
https://developercommunity.visualstudio.com/t/10294165.
Before C++20, libc++ worked around this bug by relying on
`-fdelayed-template-parsing`. However, this non-conforming option is off
by default since C++20. I think we should use `requires` instead.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Adds explanation why `is_constructible` evaluates to false.
This reapplies as-is e476f968bc8e438a0435d10934f148de570db8eb.
This was reverted in 16d5db71b3c38f21aa17783a8758f947dca5883f because of
a test failure in libc++.
The test failure in libc++ is interesting in that, in the absence of
nested diagnostics a bunch of diagnostics are emitted as error instead
of notes, which we cannot silence with `-verify-ignore-unexpected`.
The fix here is to prevent the diagnostics to be emitted in the first
place.
However this is clearly not ideal and we should make sure to deploy a
better solution in the clang 22 time frame, in the lines of
https://discourse.llvm.org/t/rfc-add-a-new-text-diagnostics-format-that-supports-nested-diagnostics/87641/12Fixes#150601
---------
Co-authored-by: Shamshura Egor <164661612+egorshamshura@users.noreply.github.com>
The SFINAE isn't required, since the primary `tuple` class already does
the SFINAE checks. This removes a bit of code that was only used for
these constraints.
This also moves the `tuple_element` specialization for `tuple` to
`__fwd/tuple.h` to avoid a dependency on `__tuple/sfinae_helpers.h`
(which should be moved in a follow-up).
And constrain the new `operator==` since C++26.
This patch implements parts of P2165R4, P2944R3, and a possibly improved
resolution of LWG3882. Currently, libstdc++ and MSVC STL constrain the
new overloads in the same way.
Also set feature-test macro `__cpp_lib_constrained_equality` and add
related release note, as P2944R3 will completed with this patch.
Fixes#136765Fixes#136770Fixes#105424
This reverts commit e476f968bc8e438a0435d10934f148de570db8eb.
It has introduced a failure tracked by https://github.com/llvm/llvm-project/issues/150601
One libcxx test fail if libcxx is build with no exceptions and no RTTI:
- libcxx/utilities/expected/expected.expected/value.observers.verify.cpp
Starting and ending parameters are considered to decide that a range is
a correct one
Fix#51028
Co-authored-by: alexey.lazarev <alexey.lazarev@tasking.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
The internal API is a lot more complicated than it actually needs to be.
This refactors the internal API to match the features and names of the
public one.
This was added to to_ulong.pass.cpp years ago by
cf1dc8d39e2c9870468ca86f7956a65c7745fece but I don't think the other
part of that commit matters here.
* Upgrade from r536225 to r563880.
* Upgrade from ab/12644632 to f8b85cc5262c6e5cbc9a92c1bab2b18b32a4c63f,
the current HEAD commit of
https://android.googlesource.com/platform/prebuilts/ndk/+/refs/heads/mirror-goog-main-ndk
The previous source of sysroots (ci.android.com), deleted its artifacts
after a short period of time, and is currently out-of-date because of
the aosp-main turndown.
Updating the Docker image also fixes two tests.
Fixes a small annoyance where generated files have a format which does
not agree with the one checked during `code-formatter` in CI.
For example `libcxx-generate-files` updates (among possibly others) the
`*.version.compile.pass.cpp` files. Previously these files contained an
extra newline which would fail the code format check. If you update that
file manually to remove just that extra trailing newline, then
`check-generated-output` will fail due to the file's contents differing
from what's expected.
Contains a number of changes: one actual change to the py script, and
lots of resulting whitespace changes.
My process for this was:
* Update `generate_feature_test_macro_components`: just remove an extra
newline which causes the code-format step to fail
* Run `$NINJA libcxx-generate-files` to rebuild all these
`.version.pass.cpp`'s
* Watch this PR's CI run to ensure things pass (i.e. this didn't break
things worse)
Per [decl.ref],
> Because a null pointer value or a pointer past the end of an object
does not point to an object, a reference in a well-defined program
cannot refer to such things.
Note this does not fixes the new bytecode interpreter.
Fixes#48665
According to `[mem.poly.allocator.ctor]` the pointer contained in
`polymorphic_allocator` can never be null. The default constructor uses
`get_default_resource()`, which never returns null and the constructor
taking a pointer explicitly has a precondition that the pointer is
non-null.
This patch adds a warning and an assertion in case a user passes a null
pointer to `polymorphic_allocator` as well as marking `resource()` to
never return null.
This also fixes some tests which contained UB.
Fixes#148420
Both Clang and GCC diagnose invalid calls to `__builtin_launder`, which
causes duplicate diagnostics when using `std::launder` in an invalid
way. While the diagnostic message for the builtin isn't perferct, it's
definitely good enough to understand the problem and adding our own
diagnostic doesn't really make things any clearer. Because of that, this
patch simply removes the `static_assert`s and lets the compiler handle
diagnosing incorrect arguments instead. This not only simplifies our
implementation, but also improves compile times a bit, since we avoid
instantiating some type traits.
Libc++'s policy is to support only the latest released Xcode, which is
Xcode 16.x. We did update our CI jobs to Xcode 16.x, but we forgot to
update the documentation, which still mentioned Xcode 15. This patch
updates the documentation and cleans up outdated mentions of
apple-clang-15 in the test suite.
This option is similar to -Wuninitialized-const-reference, but diagnoses
the passing of an uninitialized value via a const pointer, like in the
following code:
```
void foo(const int *);
void test() {
int v;
foo(&v);
}
```
This is an extract from #147221 as suggested in [this
comment](https://github.com/llvm/llvm-project/pull/147221#discussion_r2190998730).
Currently, we try to instantiate the allocator on `__hash_value_type`,
which we don't define anymore. Instead, just use the
`map::allocator_type` to instantiate `__tree`, since that's what we
actually want anyways.
This test is currently failing in the Android CI, since the compiler
used there is too old. Once the Clang version is updated this XFAIL
should be removed again.
This fixes `insert()` calling the wrong `allocator_traits::construct` in
the associative containers by removing the special handling that lead to
the inconsistencty inside `__tree` and `__hash_table`.
Clang treats throwing/catching ObjC types differently from C++ types,
and omitting the `throw` in `std::make_exception_ptr` breaks ObjC
invariants about how types are thrown/caught.
Fixes#135089
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Added explanation why a is constructible evaluated to false. Also fixed
problem with ExtractTypeTraitFromExpression. In case std::is_xxx_v<>
with variadic pack it tries to get template argument, but fails in
expression Arg.getAsType() due to Arg.getKind() ==
TemplateArgument::ArgKind::Pack, but not
TemplateArgument::ArgKind::Type.
Reverts #144127
Fixies
https://github.com/llvm/llvm-project/pull/143309#issuecomment-2970012054
Fixes#105260
This patch applies the change as a DR to C++20. The rationale is that
the paper is more like a bug fix. It does not introduce new features, it
simply changes an existing behaviour (as a bug fix). MSVC STL DRed this
paper to C++20 as well.
This test was deadlocking on my machine.
It seems to me the intention of `in_async.wait(...)` was to wait for the
value to be set to true, which requires a call of `wait(false)` (waits
if value matches argument).
~As a drive by change scoped_lock to unique_lock, since there shouldn't
be any functional difference between the two in this test.~
I've addressed the issues with the `in_async` by switching to a
condition variable instead, since my first attempt at fixing this with
`in_async` wasn't sufficient.
Fixes#108624
This allows `flat_map::insert(Iter, Iter)` to directly forward to
underlying containers' `insert(Iter, Iter)`, instead of inserting one
element at a time, when input models "product iterator". atm,
`flat_map::iterator` and `zip_view::iterator` are "product iterator"s.
This gives about almost 10x speed up in my benchmark with -03 (for both
before and after)
```cpp
Benchmark Time CPU Time Old Time New CPU Old CPU New
-----------------------------------------------------------------------------------------------------------------------------------------------
flat_map::insert_product_iterator_flat_map/32 -0.5028 -0.5320 149 74 149 70
flat_map::insert_product_iterator_flat_map/1024 -0.8617 -0.8618 3113 430 3112 430
flat_map::insert_product_iterator_flat_map/8192 -0.8877 -0.8877 26682 2995 26679 2995
flat_map::insert_product_iterator_flat_map/65536 -0.8769 -0.8769 226235 27844 226221 27841
flat_map::insert_product_iterator_zip/32 -0.5844 -0.5844 162 67 162 67
flat_map::insert_product_iterator_zip/1024 -0.8754 -0.8754 3427 427 3427 427
flat_map::insert_product_iterator_zip/8192 -0.8934 -0.8934 28134 3000 28132 3000
flat_map::insert_product_iterator_zip/65536 -0.8783 -0.8783 229783 27960 229767 27958
OVERALL_GEOMEAN -0.8319 -0.8332 0 0 0 0
```
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This patch is very similar to #134819 in nature. Before this patch, we
were dereferencing pointers to objects which were never constructed. Now
we always assume that nodes store `pair<const KeyT, ValueT>` for
unordered_maps instead, as they actually do.
