This implements a warning that's similar to what GCC does in that
context: both memcpy and memset require their first and second operand
to be trivially copyable, let's warn if that's not the case.
Around half of the tests are based on the tests Arthur O'Dwyer's
original implementation of std::flat_map, with modifications and
removals.
partially implement #105190
MSVC STL's test suite is a bit nervous about replacing non-macro-defined
identifiers with `0` (see also
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4668?view=msvc-170).
On MSVC (and MS-compatible mode of other compilers), `long double` has
the same format (IEEE-754 binary64) as `double`, so it should be OK to
define `TEST_LONG_DOUBLE_IS_DOUBLE` when `_MSC_VER` is defined. Such
detection should be performed first.
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
Make __libcpp_verbose_abort() noexcept (it is already noreturn), to
match std::terminate(). Clang's function effect analysis can use this to
ignore such functions as being beyond its scope. (See
https://github.com/llvm/llvm-project/pull/99656).
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
This is already tested in
`std/utilities/smartptr/unique.ptr/unique.ptr.class/unique.ptr.ctor/default.pass.cpp`
except that `TEST_CONSTINIT` doesn't do anything before C++20 without
this patch.
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
The poisoned_hash_helper header was relying on an implicit forward
declaration of std::hash located in <type_traits>. When we improve the
modularization of the library, that causes issues, in addition to being
a fundamentally non-portable assumption in the test suite.
It turns out that the reason for relying on a forward declaration is to
be able to test that std::hash is *not* provided if we don't include any
header that provides it. But testing that is actually both non-portable
and not really useful.
Indeed, what harm does it make if additional headers provide std::hash
specializations? That would certainly be conforming -- the Standard
never requires an implementation to avoid providing a declaration when a
given header is included, instead it mandates what *must* be provided
for sure. In that spirit, it would be conforming for e.g. `<cstddef>` to
define the hash specializations if that was our desire. I also don't
read https://wg21.link/P0513R0 as going against that statement. Hence,
this patch just removes that test which doesn't carry its weight.
Fixes#56938
We waited before supporting std::jthread fully because we wanted to
investigate other implementation strategies (in particular one involving
std::mutex). Since then, we did some benchmarking and decided that we
wouldn't be moving forward with std::mutex. Hence, there is no real
reason to punt on making std::jthread & friends non-experimental.
The resolution of LWG2593 didn't require the standard library
implementation to change. It merely strengthened requirements on
user-defined allocator types and allowed the implementation to make
stronger assumptions. The status is tentatively set to Nothing To Do.
However, `test_allocator` in libc++'s test suit needs to be fixed to
conform to the strengthened requirements.
Closes#100220.
This patch implements https://wg21.link/P2747R2.
The library changes affect direct `operator new` and `operator new[]`
calls even when the core language changes are absent.
The changes are not available for MS ABI because the `operator new` and
`operator new[]` are from VCRuntime's `<vcruntime_new.h>`. A feature
request was submitted for that [1].
As a drive-by change, the patch reformatted the whole `new.pass.cpp` and
`new_array.pass.cpp` tests.
Closes#105427
[1]: https://developercommunity.visualstudio.com/t/constexpr-for-placement-operator-newope/10730304.
Followup to #99570.
* `TEST_COMPILER_MSVC` must be tested for `defined`ness, as it is
everywhere else.
+ Definition:
52a7116f5c/libcxx/test/support/test_macros.h (L71-L72)
+ Example usage:
52a7116f5c/libcxx/test/std/utilities/function.objects/func.not_fn/not_fn.pass.cpp (L248)
+ Fixes: `llvm-project\libcxx\test\support\atomic_helpers.h(33): fatal
error C1017: invalid integer constant expression`
* Fix bogus return type: `msvc_is_lock_free_macro_value()` returns `2`
or `0`, so it needs to return `int`.
+ Fixes: `llvm-project\libcxx\test\support\atomic_helpers.h(41): warning
C4305: 'return': truncation from 'int' to 'bool'`
* Clarity improvement: also add parens when mixing bitwise with
arithmetic operators.
This patch hardens the "test iterators" we use to test algorithms by
ensuring that they don't get double-moved. As a result of this
hardening, the tests started reporting multiple failures where we would
double-move iterators, which are being fixed in this patch.
In particular:
- Fixed a double-move in pstl.partition
- Add coverage for begin()/end() in subrange tests
- Fix tests for ranges::ends_with and ranges::contains, which were
incorrectly calling begin() twice on the same subrange containing
non-copyable input iterators.
Fixes#100709
Summary:
This used an old name I forgot to fix, linter didn't catch it because it
was behind `ifdef` and the branch which I tested it on I forgot to
update the one I landed.
Summary:
The `aligned_alloc` function is the C11 replacement for
`posix_memalign`. We should favor the C standard over the POSIX standard
so more C library implementations can run the tests.
Summary:
These assembly constraints are illegal / invalid on the AMDGPU target.
The `r` constraint is only valid on inputs and the `m` constraint isn't
accepted at all. The NVPTX target can handle them because it uses a more
permissive virtual machine (PTX is an IR). Simply add exceptions on the
target to make these work.
Summary:
This utility function gets a temp file to use for tests. It either uses
WIN32 or POSIX to create it. Some targets only follow the C standard,
and this test case will fail. This patch simply adds a fallback that
uses the `tmpnam` function from standard C. This function isn't ideal,
but it is good enough for our use-case.
---------
Co-authored-by: Mark de Wever <zar-rpg@xs4all.nl>
This adds addressof at the required places in [input.output]. Some of
the new tests failed since string used operator& internally. These have
been fixed too.
Note the new fstream tests perform output to a basic_string instead of a
double. Using a double requires num_get specialization
num_get<CharT, istreambuf_iterator<CharT,
char_traits_operator_hijacker<CharT>>
This facet is not present in the locale database so the conversion would
fail due to a missing locale facet. Using basic_string avoids using the
locale.
As a drive-by fixes several bugs in the ofstream.cons tests. These
tested ifstream instead of ofstream with an open mode.
Implements:
- LWG3130 [input.output] needs many addressof
Closes#100246.
This is in relation to mr #93350. It was merged to main, but reverted
because of failing sanitizer builds on PowerPC.
The fix includes replacing the hard-coded threshold constants (e.g.
`__overflow_threshold`) for different floating-point sizes by a general
computation using `std::ldexp`. Thus, it should now work for all architectures.
This has the drawback of not being `constexpr` anymore as `std::ldexp`
is not implemented as `constexpr` (even though the standard mandates it
for C++23).
Closes#92782
In the tests I added for `ranges::find_last{_if{_not}}`, I accidentally
introduced an assumption that `same_as<array<T, 0>::iterator, T*>`; this
is a faulty assumption on MSVC-STL.
Fixes#100498.
The builtin __atomic_always_lock_free takes into account the type of the
pointer provided as the second argument. Because we were passing void*,
rather than T*, the calculation failed. This meant that
atomic_ref<T>::is_always_lock_free was only true for char & bool.
This bug exists elsewhere in the atomic library (when using GCC, we fail
to pass a pointer at all, and we fail to correctly align the atomic like
_Atomic would).
This change also attempts to start sorting out testing difficulties with
this function that caused the bug to exist by using the
__GCC_ATOMIC_(CHAR|SHORT|INT|LONG|LLONG|POINTER)_IS_LOCK_FREE predefined
macros to establish an expected value for `is_always_lock_free` and
`is_lock_free` for the respective types, as well as types with matching
sizes and compatible alignment values.
Using these compiler pre-defines we can actually validate that certain
types, like char and int, are actually always lock free like they are on
every platform in the wild.
Note that this patch was actually authored by Eric Fiselier but I picked
up the patch and GitHub won't let me set Eric as the primary author.
Co-authored-by: Eric Fiselier <eric@efcs.ca>
This implements the requirements for the container iterator requirements
for array, deque, vector, and `vector<bool>`.
Implements:
- LWG3352 strong_equality isn't a thing
Implements parts of:
- P1614R2 The Mothership has Landed
Fixes: https://github.com/llvm/llvm-project/issues/62486
The 3-dimentionsional `std::hypot(x,y,z)` was sub-optimally implemented.
This lead to possible over-/underflows in (intermediate) results which
can be circumvented by this proposed change.
The idea is to to scale the arguments (see linked issue for full
discussion).
Tests have been added for problematic over- and underflows.
Closes#92782
One-sided binary search, aka meta binary search, has been in the public
domain for decades, and has the general advantage of being constant time
in the best case, with the downside of executing at most 2*log(N)
comparisons vs classic binary search's exact log(N). There are two
scenarios in which it really shines: the first one is when operating
over non-random-access iterators, because the classic algorithm requires
knowing the container's size upfront, which adds N iterator increments
to the complexity. The second one is when traversing the container in
order, trying to fast-forward to the next value: in that case the
classic algorithm requires at least O(N*log(N)) comparisons and, for
non-random-access iterators, O(N^2) iterator increments, whereas the
one-sided version will yield O(N) operations on both counts, with a
best-case of O(log(N)) comparisons which is very common in practice.
This patch contains a number of small portability improvements for the
test suite, making it easier to run the test suite with other standard
library implementations.
- Guard checks for _LIBCPP_HARDENING_MODE to avoid -Wundef
- Avoid defining _LIBCPP_HARDENING_MODE even when no hardening mode is
specified -- we should use the default mode of the library in that case.
- Add missing includes and qualify a few function calls.
- Avoid opening namespace std to forward declare stdlib containers. The
test suite should represent user code, and user code isn't allowed to do
that.
This significantly simplifies the implementation and improves the
codegen. The only downside is that the accuracy can be marginally worse,
but that is up to the compiler to decide with this change, which means
it can be controlled by compiler flags.
Differential Revision: https://reviews.llvm.org/D155312
This changes the `is_swappable` implementation to use variable templates
first and basing the class templates on that. This avoids instantiating
them when the `_v` versions are used, which are generally less resource
intensive.
The return of malloc is implementation defined when the requested size
is 0. On platforms (such as AIX) that return a null pointer for 0 size,
operator new will throw a bad_alloc exception. operator new should
return a non null pointer for 0 size instead.
Three unrelated, small improvements:
* `test_macros.h` was incorrectly saying `__has_include("<version>")`
instead of `__has_include(<version>)`.
+ This caused `<ciso646>` to always be included (noticed because MSVC's
STL emitted a deprecation warning).
+ I searched all of LLVM and found no other occurrences.
* `thread.condition.condvarany/wait_for_pred.pass.cpp` forgot to test
anything.
+ I followed what `wait_for.pass.cpp` is testing.
* Uncomment spaceship test coverage.
* Guard `std::__make_from_tuple_impl` tests with `#ifdef _LIBCPP_VERSION` and `LIBCPP_STATIC_ASSERT`.
* Change `_LIBCPP_CONSTEXPR_SINCE_CXX20` to `TEST_CONSTEXPR_CXX20`.
+ Other functions in `variant.swap/swap.pass.cpp` were already using the proper test macro.
* Mark `what` as `[[maybe_unused]]` when used by `TEST_LIBCPP_REQUIRE`.
+ This updates one occurrence in `libcxx/test/libcxx` for consistency.
* Windows `_putenv_s()` takes 2 arguments, not 3.
+ See MSVC documentation: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/putenv-s-wputenv-s?view=msvc-170
+ POSIX `setenv()` takes `int overwrite`, but Windows `_putenv_s()` always overwrites.
* Avoid non-Standard zero-length arrays.
+ Followup to #74183 and #79792.
* Add `operator++()` to `unsized_it`.
+ The Standard requires this due to [N4981][] [move.iter.requirements]/1 "The template parameter `Iterator` shall
either meet the *Cpp17InputIterator* requirements ([input.iterators])
or model `input_iterator` ([iterator.concept.input])."
+ MSVC's STL requires this because it has a strengthened exception
specification in `move_iterator` that inspects the underlying iterator's
increment operator.
* `uniform_int_distribution` forbids `int8_t`/`uint8_t`.
+ See [N4981][] [rand.req.genl]/1.5. MSVC's STL enforces this.
+ Note that when changing the distribution's `IntType`, we need to be
careful to preserve the original value range of `[0, max_input]`.
* fstreams are constructible from `const fs::path::value_type*` on wide systems.
+ See [ifstream.cons], [ofstream.cons], [fstream.cons].
* In `msvc_stdlib_force_include.h`, map `_HAS_CXX23` to `TEST_STD_VER` 23 instead of 99.
+ On 2023-05-23, 71400505ca
started recognizing 23 as a distinct value.
* Fix test name typo: `destory_elements.pass.cpp` => `destroy_elements.pass.cpp`
[N4981]: https://wg21.link/N4981
Found while running libc++'s tests with MSVC's STL.
* Avoid MSVC warning C5101: use of preprocessor directive in
function-like macro argument list is undefined behavior.
+ We can easily make this portable by extracting `const bool is_newlib`.
+ Followup to #73440.
+ See #73598.
+ See #73836.
* Avoid MSVC warning C4267: 'return': conversion from 'size_t' to 'int',
possible loss of data.
+ This warning is valid, but harmless for the test, so
`static_cast<int>` will avoid it.
* Avoid MSVC warning C4146: unary minus operator applied to unsigned
type, result still unsigned.
+ This warning is also valid (the scenario is sometimes intentional, but
surprising enough that it's worth warning about). This is a C++17 test,
so we can easily avoid it by testing `is_signed_v` at compile-time
before testing `m < 0` and `n < 0` at run-time.
* Silence MSVC warning C4310: cast truncates constant value.
+ These warnings are being emitted by `T(255)`. Disabling the warning is
simpler than attempting to restructure the code.
+ Followup to #79791.
* MSVC no longer emits warning C4521: multiple copy constructors
specified.
+ This warning was removed from the compiler, since at least 2021-12-09.
This pull request is the third iteration aiming to integrate short
string annotations. This commit includes:
- Enabling basic_string annotations for short strings.
- Setting a value of `__trivially_relocatable` in `std::basic_string` to
`false_type` when compiling with ASan (nothing changes when compiling
without ASan). Short string annotations make `std::basic_string` to not
be trivially relocatable, because memory has to be unpoisoned.
- Adding a `_LIBCPP_STRING_INTERNAL_MEMORY_ACCESS` modifier to two
functions.
- Creating a macro `_LIBCPP_ASAN_VOLATILE_WRAPPER` to prevent
problematic stack optimizations (the macro modifies code behavior only
when compiling with ASan).
Previously we had issues with compiler optimization, which we understand
thanks to @vitalybuka. This commit also addresses smaller changes in
short string, since previous upstream attempts.
Problematic optimization was loading two values in code similar to:
```
__is_long() ? __get_long_size() : __get_short_size();
```
We aim to resolve it with the volatile wrapper.
This commit is built on top of two previous attempts which descriptions
are below.
Additionally, in the meantime, annotations were updated (but it
shouldn't have any impact on anything):
- https://github.com/llvm/llvm-project/pull/79292
---
Previous PR: https://github.com/llvm/llvm-project/pull/79049
Reverted:
a16f81f5e3
Previous description:
Originally merged here: https://github.com/llvm/llvm-project/pull/75882
Reverted here: https://github.com/llvm/llvm-project/pull/78627
Reverted due to failing buildbots. The problem was not caused by the
annotations code, but by code in the `UniqueFunctionBase` class and in
the `JSON.h` file. That code caused the program to write to memory that
was already being used by string objects, which resulted in an ASan
error.
Fixes are implemented in:
- https://github.com/llvm/llvm-project/pull/79065
- https://github.com/llvm/llvm-project/pull/79066
Problematic code from `UniqueFunctionBase` for example:
```cpp
// In debug builds, we also scribble across the rest of the storage.
memset(RHS.getInlineStorage(), 0xAD, InlineStorageSize);
```
---
Original description:
This commit turns on ASan annotations in `std::basic_string` for short
stings (SSO case).
Originally suggested here: https://reviews.llvm.org/D147680
String annotations added here:
https://github.com/llvm/llvm-project/pull/72677
Requires to pass CI without fails:
- https://github.com/llvm/llvm-project/pull/75845
- https://github.com/llvm/llvm-project/pull/75858
Annotating `std::basic_string` with default allocator is implemented in
https://github.com/llvm/llvm-project/pull/72677 but annotations for
short strings (SSO - Short String Optimization) are turned off there.
This commit turns them on. This also removes
`_LIBCPP_SHORT_STRING_ANNOTATIONS_ALLOWED`, because we do not plan to
support turning on and off short string annotations.
Support in ASan API exists since
dd1b7b797a.
You can turn off annotations for a specific allocator based on changes
from
2fa1bec7a2.
This PR is a part of a series of patches extending AddressSanitizer C++
container overflow detection capabilities by adding annotations, similar
to those existing in `std::vector` and `std::deque` collections. These
enhancements empower ASan to effectively detect instances where the
instrumented program attempts to access memory within a collection's
internal allocation that remains unused. This includes cases where
access occurs before or after the stored elements in `std::deque`, or
between the `std::basic_string`'s size (including the null terminator)
and capacity bounds.
The introduction of these annotations was spurred by a real-world
software bug discovered by Trail of Bits, involving an out-of-bounds
memory access during the comparison of two strings using the
`std::equals` function. This function was taking iterators
(`iter1_begin`, `iter1_end`, `iter2_begin`) to perform the comparison,
using a custom comparison function. When the `iter1` object exceeded the
length of `iter2`, an out-of-bounds read could occur on the `iter2`
object. Container sanitization, upon enabling these annotations, would
effectively identify and flag this potential vulnerability.
If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com
#84050 resolves class member access expressions naming members of the
current instantiation prior to instantiation. In testing, it has
revealed a mem-initializer in the move constructor of
`invocable_with_telemetry` that uses an unparenthesized comma expression
to initialize a non-static data member of pointer type. This patch fixes it.
Previously, tests for whether comparison using == was supported by
iterators derived from ranges adaptors was spread throughout the testing
codebase. This PR centralizes the implementation of those tests.
