This patch does two things:
- Remove exception specifications of `= default`ed special member
functions
- `= default` special member functions
The first part is NFC because the explicit specification does exactly
the same as the implicit specification. The second is NFC because it
does exactly what the `= default`ed special member does.
MSVC's STL marks `std::make_shared`, `std::allocate_shared`,
`std::bitset::to_ulong`, and `std::bitset::to_ullong` as
`[[nodiscard]]`, which causes these libcxx tests to emit righteous
warnings. They should use the traditional `(void)` cast technique to
ignore the return values.
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
These invariants are always expected to hold, however it's not always
clear that they do. Adding explicit checks for these invariants inside
non-trivial functions of basic_streambuf makes that clear.
Implement P2255R2 tuple.apply part wording for `std::make_from_tuple`.
```
Mandates: If tuple_size_v<remove_reference_t<Tuple>> is 1, then reference_constructs_from_temporary_v<T, decltype(get<0>(declval<Tuple>()))> is false.
```
Fixes#154274
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Resolves#105430
- Implement all required pieces of P3168R2
- Leverage existing `wrap_iter` and `bounded_iter` classes to implement
the `optional` regular and hardened iterator type, respectively
- Update documentation to match
Per [range.access.general]/1, these CPOs are also provided in
`<iterator>`. Currently only some of them are provided via transitive
inclusion when only `<iterator>` is included.
Drive-by: Add an entry for `ranges::reserve_hint` in the general test
file for CPOs.
When assertions are enabled it is impossible to construct a
`string_view` which contains a null pointer and a non-zero size, so
assertions where we check for that on an already constructed
`string_view` are unreachable.
This patch bumps the runner version in the libcxx container image. Here
we update the runner image without updating the rest of the container.
We would probably be fine updating everything, but this lets us test the
new workflow for updating the runner binary independently.
This also removes some tests which were redundant, wrong, or never run.
Specifically,
- `libcxx/utilities/meta/stress_tests/*` were never run and are of
questionable usefulness
- `libcxx/utilities/template.bitset/includes.pass.cpp` is completely
redundant and partially incorrect
Also notably,
`libcxx/language.support/support.c.headers/support.c.headers.other/math.lerp.verify.cpp`
has been refactored to only test the standard mandate.
`__is_nothrow_invocable` isn't used in C++03, so we never noticed that
it's not `constexpr`. This is caught by the clang-tidy ADL check
with LLVM 22, since it's treated like a normal function call in C++03.
It's only caught with LLVM 22, since `__builtin_invoke` wasn't available
before.
This patch fixes the libcxx container build. There was a missing env
variable that would cause the containers to not be built. Now that clang
22 is out, we also want to bump the LLVM head version to 22.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
The `__get_value()` member function was removed in LLVM 21, but the
calls in `<map>` weren't removed. This patch completes the removal and
adds regression test cases.
Fixes#152543.
Removing the unnecessary friend declarations from `<__tree>` also
removes the need for forward declaration headers for `map` and `set`,
which this patch also removes.
Add information to the libcxx testing documentation, about the names of
the new CI libcxx runner sets, their current values, and how to change
the values or the runner set being used.
This has been introduced by #151304. This problem is diagnosed by UBSan
with optimizations enabled. Since we run UBSan only with optimizations
disabled currently, this isn't caught in our CI. We should look into
enabling UBSan with optimizations enabled to catch these sorts of issues
before landing a patch.
This has been introduced by #151304. This problem is diagnosed by UBSan
with optimizations enabled. Since we run UBSan only with optimizations
disabled currently, this isn't caught in our CI. We should look into
enabling UBSan with optimizations enabled to catch these sorts of issues
before landing a patch.
This fixes failures in a number of tests, in the
clang-cl-no-vcruntime configuration (where libcxx provides dummy, no-op
replacements of some vcruntime base exception classes), if building with
optimization enabled.
Previously, with optimization enabled, the compiler concluded that these
fields would be uninitialized at the points of asserts in the tests.
This fixes the following tests in this configuration:
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.dynamic/alloc.errors/bad.alloc/bad_alloc.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.dynamic/alloc.errors/new.badlength/bad_array_new_length.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.exception/bad.exception/bad_exception.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.exception/exception/exception.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.rtti/bad.cast/bad_cast.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.rtti/bad.typeid/bad_typeid.pass.cpp
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 commit addresses a seemingly unintentional return type of the ilogb
overload taking a double. Currently it returns double, while it is
supposed to return int.
The return types seems to be covered by libcxx/test/std/numerics/c.math/cmath.pass.cpp,
but the issue would only show up if we tested with a libc that doesn't
provide the ilogb(double) overload, which we don't.
Libc++ hardening went through several iterations, sometimes within a
single release. However, some folks in the wild have picked up these
macros that were either public at some point or that were used
temporarily on `main`, and unfortunately those are now ignored.
This can lead to some users thinking they enable hardening when in
reality they don't, which is a pretty big deal. This patch simply checks
various old hardening-related macros and ensures that they are not set,
which will catch such misuse.
The current assertion failure messages produced by Hardening are not
very grep-friendly (the common part is rarther generic and requires
wildcards to match). While it's possible to use `__FILE__` for grepping,
it's easier and more straighforward to simply add a libc++-specific
prefix; this is especially important for the planned `observe` mode that
might produce many assertion failure messages over the course of the
program's execution that later need to be filtered and examined.
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
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library Hardening
(one particular benefit is that using the `observe` semantic makes adopting
hardening easier for projects).
