Previously, assignment to a std::basic_string type with a _custom_
allocator could under certain conditions attempt to interpret part of
the target string's "short" string-content as if it was a "long" data
pointer, and attempt to deallocate a garbage value.
This is a serious bug, but code in which it might happen is rare. It
required:
1. the basic_string must be using a custom allocator type which sets the
propagate_on_container_copy_assignment trait to true (thus, it does not
affect the default allocator, nor most custom allocators).
2. the allocator for the target string must compare not equal to the
allocator for the source string (many allocators always compare equal).
3. the source of the copy must currently contain a "long" string, and
the assignment-target must currently contain a "short" string.
Finally, the issue would've typically been innocuous when the bytes
misinterpreted as a pointer were all zero, as deallocating a nullptr is
typically a no-op. This is why existing test cases did not exhibit an
issue: they were all zero-length strings, which do not have data in the
bytes interpreted as a pointer.
- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.
(Note: this patch is split from https://reviews.llvm.org/D142335)
Differential Revision: https://reviews.llvm.org/D149832
I made sure they all had some expected-error output in them. Many of
these tests would be better implemented as a positive test using SFINAE,
but this is beyond the scope of this patch.
Differential Revision: https://reviews.llvm.org/D153980
Some tests in our test suite are unbelievably slow on GCC due to the
use of the always_inline attribute. See [1] for more details.
This patch introduces the GCC-ALWAYS_INLINE-FIXME lit feature to
disable tests that are plagued by that issue. At the same time, it
moves several existing tests from ad-hoc `UNSUPPORTED: gcc-12` markup
to the new GCC-ALWAYS_INLINE-FIXME feature, and marks the slowest tests
reported by the CI as `UNSUPPORTED: GCC-ALWAYS_INLINE-FIXME`.
[1]: https://discourse.llvm.org/t/rfc-stop-supporting-extern-instantiations-with-gcc/71277/1
Differential Revision: https://reviews.llvm.org/D152736
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: #libc, kwk, Mordante
Differential Revision: https://reviews.llvm.org/D150763
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Note since we use clang-tidy 16 a small work-around is needed. Clang
knows -std=c++23 but clang-tidy not so for now force the lit compiler
flag to use -std=c++2b instead of -std=c++23.
Reviewed By: #libc, philnik, jloser, ldionne
Differential Revision: https://reviews.llvm.org/D150795
We plan to add concepts for checking that iterators actually provide what they claim to. This is to avoid people thinking that these type traits actually check the iterator requirements in more detail.
Reviewed By: ldionne, #libc
Spies: Mordante, libcxx-commits, wenlei
Differential Revision: https://reviews.llvm.org/D150801
In libc++'s `wchar.h`, before we forward to the system `wchar.h`, we set `__CORRECT_ISO_CPP_WCHAR_H_PROTO` to ensure it defines the correct signature (e.g. `extern "C++" const wchar_t *wmemchr` and not `extern wchar_t *wmemchr`). After D148542, there are cases where we include the system `wchar.h` from within `__mbstate_t.h` without setting that, and so we get a function type mismatch if we transitively include `wchar.h` through multiple headers in a modules-enabled build. Consistently setting it here resolves those build errors.
Alternative 1: we could put this in `__config` instead. I chose to put it here for a more limited scope.
Alternative 2: we could patch `wchar.h` itself to work correctly and remove references `__CORRECT_ISO_CPP_WCHAR_H_PROTO` from libc++ entirely. It does already set it, but with an additional condition that it is being built by GCC >= 4.4. Clang does pretend to be GCC via `__GNUC__` etc. which can be controlled via `-fgnuc-version` command line flags, but that might have other consequences.
Reviewed By: ldionne, #libc, MaskRay
Differential Revision: https://reviews.llvm.org/D150015
These test cases were fixed with AIX 73TL1, and are currently passing on AIX machines with that fix. This fix has also been backported to the 7.2 service line. These were tested on a machine with AIX 7.2 TL 5 SP4 installed.
Differential Revision: https://reviews.llvm.org/D148040
The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).
This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.
Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.
Differential Revision: https://reviews.llvm.org/D146366
This has been done using the following commands
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)ptrdiff_t)|\1std::\2|' \{} \;
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)max_align_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.,
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146550
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
The `std` module doesn't export `::size_t`, this is a preparation for that module.
Reviewed By: ldionne, #libc, EricWF, philnik
Differential Revision: https://reviews.llvm.org/D146088
We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.
As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.
Differential Revision: https://reviews.llvm.org/D146236
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?int(_[a-z]+)?[0-9]{1,2}_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145880
Avoids using operator& in basic_string since an evil char-like type can
hijack this operator. Added some more evil operators, this found a place
where equality was compared directly and not via the traits.
This adds a helper test string. This is now only used in a few tests,
but the intention is to use this in more tests for basic_string.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D145257
First, fix a collision with the Point type from MacTypes.h, which was
reported on Slack, 2022-07-31: https://cpplang.slack.com/archives/C2X659D1B/p1659284691275889
Second, rename the meta:: namespace to types::. OSX's "/usr/include/ncurses.h"
defines a `meta` function, and is (for some reason) included in
"<SDK>/usr/include/module.modulemap", so that identifier is off-limits
for us to use in anything that compiles with -fmodules:
libcxx/test/support/type_algorithms.h:16:11: error: redefinition of 'meta' as different kind of symbol
namespace meta {
^
<SDK>/usr/include/ncurses.h:603:28: note: previous definition is here
extern NCURSES_EXPORT(int) meta (WINDOW *,bool); /* implemented */
^
Finally, add a CI configuration for modules on OS X to make sure it
does not regress.
Differential Revision: https://reviews.llvm.org/D144915
The `basic_string_view` constructor accepting a contiguous range rejects
converting between `basic_string_view` even when only the trait types vary.
This prevents conversions for converting from `basic_string_view<C, T1>` and
`basic_string<C, T1, A>` to `basic_string_view<C, T2>`. Recently, this
constructor was made `explicit`, so there's no reason to really forbid this
conversion anymore.
Relax the restriction that the trait types need to match in this constructor.
Differential Revision: https://reviews.llvm.org/D143972
When support for declaring the c8rtomb() and mbrtoc8() functions within the
std namespace was added in commit 7e7013c5d4b1b3996c8dba668c5a94bb33b2999b,
internal glibc macros were used to determine if C2X extensions are enabled.
Specifically, a check for whether `__GLIBC_USE` is defined and whether
`__GLIBC_USE(ISOC2X)` is non-0 was added. `__GLIBC_USE` is an internal
detail of the glibc implementation that may be changed or removed in the
future potentially leading to inconsistency or compilation failures. This
change removes the use of the internal glibc macro to avoid such problems.
Unfortunately, without another mechanism to determine if C2X extensions are
enabled, this removal will result in inconsistent declarations of the
c8rtomb() and mbrtoc8() functions; when C++ char8_t support is not enabled, but
C2X extensions are, these functions will be declared in the global namespace
but not in the std namespace. This situation will improve when C23 support
is finalized and the check can be re-implemented using `__STDC_VERSION__`.
* Using one-or-two letter names for globals is asking for shadowing warnings.
* MSVCSTL's container proxy allocations strike again
* MSVCSTL's `<string>` doesn't define `std::out_of_range`
* `basic_string::substr` takes two arguments of type `size_type`. Let's use that type instead of `size_t` and `ptrdiff_t` to avoid narrowing warnings.
Differential Revision: https://reviews.llvm.org/D141253
The converting constructor is ill-formed, and `==` is missing. (I didn't implement `!=` since the test is C++20-and-later only; I'll let the compiler do it for us.)
Drive-by: change 4-space indent on line 27 to 2-space indent to be consistent with the rest of the test.
Differential Revision: https://reviews.llvm.org/D131079
When we define the const-correct overloads of <string.h> functions in
libc++ itself, use builtins whenever possible. This avoids depending on
the presence of these functions in the C library headers.
Also, as a fly-by, improve the tests for these functions since we
basically didn't check anything but their signature. We could have
used the wrong builtin (as long as the signature matched) without ever
noticing, which was quite scary.
Differential Revision: https://reviews.llvm.org/D138684
This patch removes the base template implementation for std::char_traits.
If my reading of http://eel.is/c++draft/char.traits is correct, the
Standard mandates that the library provides specializations for several
types like char and wchar_t, but not any implementation in the base
template. Indeed, such an implementation is bound to be incorrect for
most types anyways, since things like `eof()` and `int_type` will definitely
have to be customized.
Since the base template implementation should not have worked for anyone,
this shouldn't be a breaking change (I expect that anyone defining a
custom character type today will already have to provide their own
specialization of char_traits). However, since we're aware of some users
of char_traits for unsigned char and signed char, we're keeping those two
specializations around for two releases to give people some time to migrate.
Differential Revision: https://reviews.llvm.org/D138307
We currently call a lot of functions with the same list of types. To avoid forgetting any of them, this patch adds type_lists and utilities for it. Specifically, it adds
- `type_list` - This is just a list of types
- `concatenate` - This allows concatenating type_lists
- `for_each` - Iterate over a type_list
Reviewed By: ldionne, #libc
Spies: jloser, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D137476
This doesn't affect our ABI because `std::string::substr()` isn't in the dylib and the mangling of `substr() const` and `substr() const&` are different.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, #libc
Spies: arphaman, huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D131668
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d828 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
This change implements the C library dependent portions of P0482R6
(char8_t: A type for UTF-8 characters and strings (Revision 6)) by
declaring std::c8rtomb() and std::mbrtoc8() in the <cuchar> header
when implementations are provided by the C library as specified by
WG14 N2653 (char8_t: A type for UTF-8 characters and strings
(Revision 1)) as adopted for C23.
A _LIBCPP_HAS_NO_C8RTOMB_MBRTOC8 macro is defined by the libc++ __config
header unless it is known that the C library provides these functions
in the current compilation mode. This macro is used for testing purposes
and may be of use to libc++ users. At present, the only C library known
to implement these functions is GNU libc as of its 2.36 release.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D130946
For some reason `operator""s(const char8_t*, size_t)` was marked `noexcept`. Remove it and add regression tests.
Reviewed By: ldionne, huixie90, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D132340
Many tests in `libcxx/test/std/strings` use
`#if defined(__cpp_lib_char8_t) && __cpp_lib_char8_t >= 201811L`
which can be replaced with the more terse `#ifndef TEST_HAS_NO_CHAR8_T`.
Differential Revision: https://reviews.llvm.org/D132626
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
While implementing `operator<=>` for `string_view` (D130295) @philnik
pointed out `common_type` should be `type_identity`. Since it was an
existing issue that wasn't addressed.
This addresses the issue for both the new and existing equality and
comparison operators. The test is based on the example posted in
D130295.
Reviewed By: philnik, #libc, huixie90
Differential Revision: https://reviews.llvm.org/D131322
