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
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).
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
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.
The checks for the 'z' and 't' format specifiers added in the original
PR #143653 had some issues and were overly strict, causing some build
failures and were consequently reverted at
4c85bf2fe8.
In the latest commit
27c58629ec,
I relaxed the checks for the 'z' and 't' format specifiers, so warnings
are now only issued when they are used with mismatched types.
The original intent of these checks was to diagnose code that assumes
the underlying type of `size_t` is `unsigned` or `unsigned long`, for
example:
```c
printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long
```
However, it produced a significant number of false positives. This was
partly because Clang does not treat the `typedef` `size_t` and
`__size_t` as having a common "sugar" type, and partly because a large
amount of existing code either assumes `unsigned` (or `unsigned long`)
is `size_t`, or they define the equivalent of size_t in their own way
(such as
sanitizer_internal_defs.h).2e67dcfdcd/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h (L203)
Including the results of `sizeof`, `sizeof...`, `__datasizeof`,
`__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and
signed `size_t` literals, the results of pointer-pointer subtraction and
checks for standard library functions (and their calls).
The goal is to enable clang and downstream tools such as clangd and
clang-tidy to provide more portable hints and diagnostics.
The previous discussion can be found at #136542.
This PR implements this feature by introducing a new subtype of `Type`
called `PredefinedSugarType`, which was considered appropriate in
discussions. I tried to keep `PredefinedSugarType` simple enough yet not
limited to `size_t` and `ptrdiff_t` so that it can be used for other
purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a
name, conceptually similar to a compiler internal `TypedefType` but
without depending on a `TypedefDecl` or a source file.
Additionally, checks for the `z` and `t` format specifiers in format
strings for `scanf` and `printf` were added. It will precisely match
expressions using `typedef`s or built-in expressions.
The affected tests indicates that it works very well.
Several code require that `SizeType` is canonical, so I kept `SizeType`
to its canonical form.
The failed tests in CI are allowed to fail. See the
[comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611)
in another PR #135386.
This test doesn't seem to be very useful. If it is the only test that
fails we would just remove the failing parts of the test, and otherwise
it doesn't provide any value either, since there will be another test
that fails.
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
This was probably added to support https://wg21.link/n3644 but there's
no reason not to initialize the pointer in all standard modes. This is
technically an extension since n3644 only required value-initialized
iterators to be comparable, but supporting this as an extension should
be uncontroversial since it avoids potential reads of uninitialized
memory in C++03/C++11 without doing any harm.
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.
Reverts llvm/llvm-project#148266
I'm reverting this temporarily, since the release branch is today and
this is ABI sensitive. Let's wait until after the branch so that we have
plenty time to discuss the patch.
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).
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
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.
