| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This was slated for removal in LLVM 19.
|
|
|
|
Destroying an ios_base object before it is properly initialized is
undefined behavior. Unlike typical C++ classes the initialization is not
done in the constructor, but in a dedicated init function. Due to
virtual inheritance of the basic_ios object in ostream and friends this
undefined behaviour can be triggered when inheriting from classes that
can throw in their constructor and inheriting from ostream.
Use the __loc_ member of ios_base as sentinel to detect whether the
object has or has not been initialized.
Addresses https://github.com/llvm/llvm-project/issues/57964
|
|
This allows testing the time zone information in the CI. This is needed
to let https://github.com/llvm/llvm-project/pull/82108 pass the CI.
|
|
Typically the rules in the database are contiguous, but that is not a
requirement. This fixes the case when they are not.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
Previously, `__bounded_iter` only checked `operator*`. It allowed the
pointer to go out of bounds with `operator++`, etc., and relied on
`operator*` (which checked `begin <= current < end`) to handle
everything. This has several unfortunate consequences:
First, pointer arithmetic is UB if it goes out of bounds. So by the time
`operator*` checks, it may be too late and the optimizer may have done
something bad. Checking both operations is safer.
Second, `std::copy` and friends currently bypass bounded iterator
checks. I think the only hope we have to fix this is to key on `iter +
n` doing a check. See #78771 for further discussion. Note this PR is not
sufficient to fix this. It adds the output bounds check, but ends up
doing it after the `memmove`, which is too late.
Finally, doing these checks is actually *more* optimizable. See #78829,
which is fixed by this PR. Keeping the iterator always in bounds means
`operator*` can rely on some invariants and only needs to check `current
!= end`. This aligns better with common iterator patterns, which use
`!=` instead of `<`, so it's easier to delete checks with local
reasoning.
See https://godbolt.org/z/vEWrWEf8h for how this new `__bounded_iter`
impacts compiler output. The old `__bounded_iter` injected checks inside
the loops for all the `sum()` functions, which not only added a check
inside a loop, but also impeded Clang's vectorization. The new
`__bounded_iter` allows all the checks to be optimized out and we emit
the same code as if it wasn't here.
Not everything is ideal however. `add_and_deref` ends up emitting two
comparisons now instead of one. This is because a missed optimization in
Clang. I've filed #78875 for that. I suspect (with no data) that this PR
is still a net performance win because impeding ranged-for loops is
particularly egregious. But ideally we'd fix the optimizer and make
`add_and_deref` fine too.
There's also something funny going on with `std::ranges::find` which I
have not yet figured out yet, but I suspect there are some further
missed optimization opportunities.
Fixes #78829.
(CC @danakj)
|
|
(#80230)
These are simply null checks, so use `_LIBCPP_ASSERT_NON_NULL`. This
allows us to restore a bunch of the old debug tests. I've extended them
to also cover the const iterators, as those run through different
codepaths than the const ones.
This does the easier (and less important) half of #80212.
|
|
The comment makes this error condition sound less problematic than it
is. If the length does not match the pointer's bounds, all
bounds-checking in string_view goes wrong. A length over PTRDIFF_MAX
cannot possibly be a correct bounds and was mostly an underflowed
negative number cast to a size_t.
The documentation for _LIBCPP_ASSERT_VALID_INPUT_RANGE discusses ranges
being valid, including an iterator and a count, which seemed appropriate
here.
|
|
This reverts commit aa60b2687, which was a temporary workaround.
The underlying issue was fixed in Clang via c2c840bd92cf.
This was originally https://reviews.llvm.org/D158694.
|
|
It seems that updating the compiler in the CI resolved the issue, which
causes the test to be XPASSing now.
Fixes #74327
|
|
The `128-bit-atomics` libcxx feature is incorrectly named because tests
that are Xfailed with it is really using `int[128]`. Additionally,
because toolchain support for that feature is determined based on a much
smaller size (`char[16]`), tests would execute incorrectly without
required toolchain support.
So, rename `128-bit-atomics` as `1024-bit-atomics`, and use an
appropriate type to check for the presence of the feature.
|
|
meant to be used (#84707)
This patch fixes the unconditional forward-declarations of ABI-functions
in exception_ptr.h, and makes it dependent on the availability macro, as
it should've been from the beginning.
The declarations being unconditional break the build with libcxxrt
before 045c52ce8 [1], now they are opt-out.
[1]: https://github.com/libcxxrt/libcxxrt/commit/045c52ce821388f4ae4d119fe4fb75f1eb547b85
|
|
(#83734)
The `parse.pass.cpp` tests doen't need to call
`test_format_context_create` to create a `basic_format_context`, so they
shouldn't include `test_format_context.h`.
The `to_address` mechanism works around the iterator debugging
mechanisms of MSVC STL. Related to
[LWG3989](https://cplusplus.github.io/LWG/issue3989).
Discovered when implementing `formatter<tuple>` in MSVC STL. With the
inclusion removed, `std/utilities/format/format.tuple/parse.pass.cpp`
when using enhanced MSVC STL (and `/utf-8` option for MSVC).
|
|
That test is using std::toupper.
|
|
This moves a utility from `<tuple>` into an implementation detail header
and refactors the selection of the variant index type to use.
|
|
The current selection is done in the test scripts which gives the user
no control where to find clang-tidy. The version selection itself is
hard-coded and not based on the version of clang used.
This moves the selection to configuration time and tries to find a
better match.
- Mixing the version of clang-tidy and the clang libraries causes ODR
violations. This results in practice in crashes or incorrect results.
- Mixing the version of clang-tidy and the clang binary sometimes causes
issues with supported diagnostic flags. For example, flags tested
against clang 17 may not be available in clang-tidy 16.
Currently clang-tidy 18.1 can be used, it tests against the clang
libraries version 18. This is caused by the new LLVM version numbering
scheme.
The new selection tries to match the clang version or the version of the
HEAD and the last 3 releases. (During the release period libc++ supports
4 versions instead of the typical 3 versions.)
|
|
This reduces the include time of `<span>` from 122ms to 78ms.
|
|
The specifications of format had a contradiction, libc++ always
implemented the code as-if LWG3462 has been done; the contradiction was
a bit hard to spot.
Marks as nothing to do:
- LWG3462 §[formatter.requirements]: Formatter requirements forbid use
of fc.arg()
|
|
The issue has been resolved in https://reviews.llvm.org/D121138 since it
was needed to implement format. This updates the status of the LWG-issue
filed for this review.
Marks as complete:
- LWG3701 Make formatter<remove_cvref_t<const charT[N]>, charT>
requirement explicit
|
|
`array.cons/initialization.pass.cpp` (#79793)
This fixes MSVC warning C4127: conditional expression is constant.
Testing `TEST_STD_AT_LEAST_20_OR_RUNTIME_EVALUATED` by itself doesn't
emit this warning, but the condition here is more complicated. I'm
expanding the macro and mechanically simplifying the resulting code.
(Yeah, this warning is often annoying, and I introduced
`TEST_STD_AT_LEAST_20_OR_RUNTIME_EVALUATED` to avoid this warning
elsewhere, so it's disappointing that it doesn't make the compiler happy
here. If this change is undesirable, I can replace it with
`ADDITIONAL_COMPILE_FLAGS(cl-style-warnings)`, but ideally I'd like to
avoid having to suppress it.)
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
This depends on enabling extensions in the implementation.
|
|
We've talked about allowing extensions on
[discourse](https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/5)
and in a libc++ monthly meeting and agreed to test it out in the LLVM 18
release. We've done that with the `tuple` constructor overload set
(using conditional `explicit`). Since we haven't heard about any
breakages, it seems safe to do. This patch enables the use of extension
from later C++ standards inside the versioned `std` namespaces. This
should be good enough, since almost all of our code is inside that
namespace. This approach also avoids the use of extensions inside the
test `std` suite. That part of the code base should stay clean, since
it's a test suite that is also used by other vendors to test their
implementations.
|
|
The libc++ CMake build aims to provide a general-purpose configuration
that matches the canonical LLVM setup (libc++ / libc++abi / libunwind),
not the configuration used for compatibility on any given system. For
these "compatibility" configurations, we use CMake caches like
Apple.cmake and FreeBSD.cmake.
Defaulting to libcxxrt on FreeBSD makes it look as though we're trying
to build the system compatible configuration on FreeBSD, which isn't
really correct and causes confusion more than anything else.
Fixes #84476
|
|
|
|
LIT was never really meant to generate tests during discovery,
and we probably shouldn't be doing this.
This hack is even worse than the initial attempt because it buries the
"UNSUPPORTED" at the bottom of the test.
|
|
It looks like that broke the CI even more. Reverting until I can
investigate.
|
|
Those have been crippling the CI for over a week now. This is the only
solution I see until we gain a better understanding of why they fail.
Otherwise all other patches are blocked on these spurious failures in
the stage1 of the CI.
|
|
Almost every test needed a CanBePiped concept and each implemented it
separately, but identically. Consolidate all implementations into
test_range.h.
|
|
__has_extension (#84065)
__has_extension(...) doesn't work as intended when -pedantic-errors is
used with Clang. With that flag, __has_extension(...) is equivalent to
__has_feature(...), which means that checks like
__has_extension(pragma_clang_attribute_external_declaration)
will return 0. In turn, this has the effect of disabling availability
markup in libc++, which is undesirable.
rdar://124078119
|
|
Fix output to match actual.
|
|
|
|
|
|
Yesterday, one of the issues the libc++ builders encountered was that
they were using a client that was too old; too old to even update
automatically.
To get things working, i had to push a testing image with this change.
The testing image has been working for 12 hours now, so it's time to
commit to it :-)
|
|
Fixes several minor formatting issues and omissions I introduced on the
status pages in previous patches.
|
|
(#80552)
Implements P2495R3 <https://wg21.link/P2495R3>
- https://eel.is/c++draft/version.syn#headerref:%3csstream%3e
- https://eel.is/c++draft/stringbuf
- https://eel.is/c++draft/stringbuf.general
- https://eel.is/c++draft/stringbuf.cons
- https://eel.is/c++draft/stringbuf.members
- https://eel.is/c++draft/istringstream
- https://eel.is/c++draft/istringstream.general
- https://eel.is/c++draft/istringstream.cons
- https://eel.is/c++draft/istringstream.members
- https://eel.is/c++draft/ostringstream
- https://eel.is/c++draft/ostringstream.general
- https://eel.is/c++draft/ostringstream.cons
- https://eel.is/c++draft/ostringstream.members
- https://eel.is/c++draft/stringstream
- https://eel.is/c++draft/stringstream.general
- https://eel.is/c++draft/stringstream.cons
- https://eel.is/c++draft/stringstream.members
References:
- https://eel.is/c++draft/string.streams
|
|
We normally try to issue a reasonable diagnostic when mixing
<stdatomic.h> and <atomic> before C++23. However, after granularizing
the <atomic> header, the check and the #error message was moved to
*after* the point where mixing both causes problems. When mixing both
headers, we would hence get the diagnostic burried under a pile of
previous diagnostics in e.g. __atomic/kill_dependency.h.
This patch moves the check earlier to restore the intended behavior. It
also switches from `#ifdef kill_dependency` to an explicit check of the
inclusion of the header and the Standard version, which seems to be more
reliable than checking whether a macro is defined.
|
|
std::string_view and std::array iterators don't have to be raw pointers,
and in fact other implementations don't represent them as raw pointers.
Them being raw pointers in libc++ makes it easier for users to write
non-portable code. This is bad in itself, but this is even worse when
considering efforts like hardening where we want an easy ability to
swap for a different iterator type. If users depend on iterators being
raw pointers, this becomes a build break.
Hence, this patch enables the use of __wrap_iter in the unstable ABI,
creating a long term path towards making this the default. This patch
may break code that assumes these iterators are raw pointers for
people compiling with the unstable ABI.
This patch also removes several assumptions that array iterators are
raw pointers in the code base and in the test suite.
|
|
We only define the classes in `<syncstream>` when experimental library
features are enabled, but we would forward-declare them in `<iosfwd>`
even when they are disabled. This led to confusing error messages about
being unable to instantiate an undefined template.
|
|
We actually didn't generate anything in that file, so generating it via
CMake is useless.
|
|
When echo is used for piping, lit uses the system echo rather than the
builtin echo. The system echo on AIX doesn't support the `-n` option,
which causes these tests to fail. Use input redirection, so the builtin
echo can be used.
|
|
This should have been removed in 8dcb8ea75cef, which removed support for
.fail.cpp tests in the libc++ test suite.
|
|
An immediate colon signifeis that the range-format-spec contains only
range-underlying-spec.
This patch allows this code to compile and run:
```c++
std::println("{::<<9?}", std::span<const char>{"Hello", sizeof "Hello"});
```
|
|
(#81445)
We forward declare `reference_wrapper` in multiple places already. This
moves the declaration to the canonical place and removes unnecessary
includes of `__functional/reference_wrapper.h`.
|
|
|
|
They have been added recently to GCC without support for mangling. This
patch uses them in structs and adds aliases to these structs instead of
the builtins directly.
|
|
This moves the duplicated code to one new function.
This is a preparation to fix
https://github.com/llvm/llvm-project/issues/60509
|
|
The goal of this patch is to make `atomic`'s wait functions to be
reusable by `atomic_ref`.
https://github.com/llvm/llvm-project/pull/76647
First, this patch is built on top of
https://github.com/llvm/llvm-project/pull/80596 , to reduce the future
merge conflicts.
This patch made the following functions as "API"s to be used by
`atomic`, `atomic_flag`, `semaphore`, `latch`, `atomic_ref`
```
__atomic_wait
__atomic_wait_unless
__atomic_notify_one
__atomic_notify_all
```
These functions are made generic to support `atomic` type and
`atomic_ref`. There are two customisation points.
```
// How to load the value from the given type (with a memory order)
__atomic_load
```
```
// what is the contention address that the platform `wait` function is going to monitor
__atomic_contention_address
```
For `atomic_ref` (not implemented in this patch), the `load` and
`address` function will be different, because
- it does not use the "atomic abstraction layer" so the `load` operation
will be some gcc builtin
- the contention address will be the user's actual type that the
`atomic_ref` is pointing to
|
|
As discussed in https://github.com/llvm/llvm-project/pull/81427/files#r1509266817
rename the variable as a separate commit
|
|
and__cpp_lib_ranges_starts_ends_with (#81816)
ranges::contains: fdd089b50063
ranges::starts_with: 205175578e0d
ranges::ends_with: 0218ea4aaa54
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
_LIBCPP_ASSERT_SHIM used by the -fno-exceptions and
LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=on configuration
needs _LIBCPP_ASSERT from <__assert>.
|
