| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It seems that we can only rely on C++20 features and make `nasty_string`
also tested for MSVC STL.
|
|
(#125423)
Without this patch `basic_string` cannot be properly resized to be
`max_size()` elements in size, even if an allocation is successful.
`__grow_by` allocates one less element than required, resulting in an
out-of-bounds access. At the same time, `max_size()` has an off-by-one
error, since there has to be space to store the null terminator, which
is currently ignored.
|
|
By calling `std::move` for related functions when the iterator is
possibly input-only. Also slightly changes the conditions of branch for
contiguous iterators to avoid error.
Fixes #116502
|
|
Summary:
The GPU runs these tests using the files built from the `libc` project.
These will be placed in `include/<triple>` and `lib/<triple>`. We use
the `amdhsa-loader` and `nvptx-loader` tools, which are also provided by
`libc`. These launch a kernel called `_start` which calls `main` so we
can pretend like GPU programs are normal terminal applications.
We force serial exeuction here, because `llvm-lit` runs way too many
processes in parallel, which has a bad habit of making the GPU drivers
hang or run out of resources. This allows the compilation to be run in
parallel while the jobs themselves are serialized via a file lock.
In the future this can likely be refined to accept user specified
architectures, or better handle including the root directory by exposing
that instead of just `include/<triple>/c++/v1/`.
This currently fails ~1% of the tests on AMDGPU and ~3% of the tests on
NVPTX. This will hopefully be reduced further, and later patches can
XFAIL a lot of them once it's down to a reasonable number.
Future support will likely want to allow passing in a custom
architecture instead of simply relying on `-mcpu=native`.
|
|
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 also adds a few FIXMEs where we use UB in the tests.
|
|
A quick examination suggests that the current code in the codebase does
not lead to incorrect annotations. However, the intention is for the
object after the function to be annotated in a way that only its
contents are unpoisoned and the rest is poisoned. This commit makes it
explicit and avoids potential issues in future.
In addition, I have implemented a few tests for a function that helped
me identify the specific argument value.
Notice: there is no known scenario where old code results in incorrect
annotation.
|
|
This commit introduces basic annotations for `std::basic_string`,
mirroring the approach used in `std::vector` and `std::deque`.
Initially, only long strings with the default allocator will be
annotated. Short strings (_SSO - short string optimization_) and strings
with non-default allocators will be annotated in the near future, with
separate commits dedicated to enabling them. The process will be similar
to the workflow employed for enabling annotations in `std::deque`.
**Please note**: these annotations function effectively only when libc++
and libc++abi dylibs are instrumented (with ASan). This aligns with the
prevailing behavior of Memory Sanitizer.
To avoid breaking everything, this commit also appends
`_LIBCPP_INSTRUMENTED_WITH_ASAN` to `__config_site` whenever libc++ is
compiled with ASan. If this macro is not defined, string annotations are
not enabled. However, linking a binary that does **not** annotate
strings with a dynamic library that annotates strings, is not permitted.
Originally proposed here: https://reviews.llvm.org/D132769
Related patches on Phabricator:
- Turning on annotations for short strings:
https://reviews.llvm.org/D147680
- Turning on annotations for all allocators:
https://reviews.llvm.org/D146214
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.
This Pull Request introduces basic annotations for `std::basic_string`.
Long strings exhibit structural similarities to `std::vector` and will
be annotated accordingly. Short strings are already implemented, but
will be turned on separately in a forthcoming commit. Look at [a
comment](https://github.com/llvm/llvm-project/pull/72677#issuecomment-1850554465)
below to read about SSO issues at current moment.
Due to the functionality introduced in
[D132522](https://github.com/llvm/llvm-project/commit/dd1b7b797a116eed588fd752fbe61d34deeb24e4),
the `__sanitizer_annotate_contiguous_container` function now offers
compatibility with all allocators. However, enabling this support will
be done in a subsequent commit. For the time being, only strings with
the default allocator will be annotated.
If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com
|
|
Extend `std::basic_string` tests to cover more buffer situations and
length in general, particularly non-SSO cases after SSO test cases
(changing buffers). This commit is a side effect of working on tests for
ASan annotations.
Related PR: https://github.com/llvm/llvm-project/pull/72677
|
|
Found while running libc++'s test suite with MSVC's STL.
This is structured into a series of commits for easier reviewing; I
could also split this into smaller PRs if desired.
* Add void-casts for `invoke_r` calls to fix MSVC STL `[[nodiscard]]`
warnings.
+ Our rationale is that if someone is calling `invoke_r<NonVoidType>`,
it sure looks like they care about the return value.
* Add `[[maybe_unused]]` to silence `-Wunused-parameter` warnings.
+ This happens because the parameters are used within `LIBCPP_ASSERT`,
which vanishes for MSVC's STL. This also motivates the following
changes.
* Add `[[maybe_unused]]` to fix `-Wunused-variable` warnings.
* Always void-cast `debug_comparisons` to fix `-Wunused-variable`
warnings.
+ As this was already unused with a void-cast in one
`_LIBCPP_HARDENING_MODE` branch, I'm simply lifting it next to the
variable definition.
* Add `[[maybe_unused]]` to fix `-Wunused-local-typedef` warnings.
|
|
While doing this, I also found a few tests that were either clearly
incorrect (e.g. testing the wrong function) or that lacked basic test
coverage like testing std::string itself (e.g. the test was only checking
std::basic_string with a custom allocator). In these cases, I did a few
conservative drive-by changes.
Differential Revision: https://reviews.llvm.org/D140550
Co-authored-by: Brendan Emery <brendan.emery@esrlabs.com>
|
|
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.
|
|
This applies clang-format to the std::string unit tests in preparation
for landing https://reviews.llvm.org/D140550.
Differential Revision: https://reviews.llvm.org/D140612
|
|
(`ranges::to`):
- 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
|
|
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 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
|
|
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
|
|
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
|
|
D119633
Differential Revision: https://reviews.llvm.org/D135297
|
|
Reviewed By: ldionne, #libc, huixie90
Spies: huixie90, libcxx-commits, arphaman
Differential Revision: https://reviews.llvm.org/D131856
|
|
This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose).
Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne
Differential Revision: https://reviews.llvm.org/D127470
|
|
In D122982 I accidentally disabled the memmove optimization. This re-enables it and adds more cases where copy forwards to memmove.
Fixes https://github.com/llvm/llvm-project/issues/33687
Reviewed By: var-const, #libc, ldionne
Spies: pkasting, ayzhao, dcheng, xbolva00, libcxx-commits
Differential Revision: https://reviews.llvm.org/D124328
|
|
Reviewed By: #libc, ldionne
Spies: daltenty, sdasgup3, ldionne, arichardson, MTC, ChuanqiXu, mehdi_amini, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes, tatianashp, rdzhabarov, teijeong, cota, dcaballe, Chia-hungDuan, wrengr, wenzhicui, arphaman, Mordante, miscco, Quuxplusone, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D110598
|
|
These are the last™ changes to the tests for constexpr preparation.
Reviewed By: Quuxplusone, #libc, Mordante
Spies: Mordante, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120951
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D119329
|
|
AFAICT, Cpp17InputIterators are not required to be default constructible,
since that requirement is added in Cpp17ForwardIterator. Hence, our
archetype for Cpp17InputIterator should not be default constructible.
Removing that constructor has a ripple effect on a couple of tests that
were making incorrect assumptions. Notably:
- Some tests were using cpp17_input_iterator as a sentinel for itself.
That is not valid, because a cpp17_input_iterator is not semiregular
anymore after the change (and hence it doesn't satisfy sentinel_for).
- Some tests were using a stride-counted cpp17_input_iterator as the
sentinel for a range. This doesn't work anymore because of the problem
above, so these tests were changed not to check stride counts for
input iterators.
- Some tests were default constructing cpp17_input_iterator when a simple
alternative was available -- those have been changed to use that alternative.
Differential Revision: https://reviews.llvm.org/D115806
|
|
string::assign.
This appears to be a bug in our string::assign: when assigning into
a longer string, from a shorter snippet of itself, we invalidate
iterators before doing the copy. We should invalidate them afterward.
Also drive-by improve the formatting of a function header.
Differential Revision: https://reviews.llvm.org/D101675
|
|
C++20 revised the definition of what it means to be an iterator. While
all _Cpp17InputIterators_ satisfy `std::input_iterator`, the reverse
isn't true. D100271 introduces a new test adaptor to accommodate this
new definition (`cpp20_input_iterator`).
In order to help readers immediately distinguish which input iterator
adaptor is _Cpp17InputIterator_, the current `input_iterator` adaptor
has been prefixed with `cpp17_`.
Differential Revision: https://reviews.llvm.org/D101242
|
|
To run llvm-lit manually from the command line:
./bin/llvm-lit -sv --param std=c++2b --param cxx_under_test=`pwd`/bin/clang \
--param debug_level=1 ../libcxx/test/
Tests that currently fail with `debug_level=1` are marked `LIBCXX-DEBUG-FIXME`,
but my intent is to deal with all of them and leave no such annotations in
the codebase within the next couple weeks. (I have patches for all of them
in my local checkout.)
Differential Revision: https://reviews.llvm.org/D100866
|
|
When checking the strong exception guarantee, also check that
iterators haven't been invalidated.
Reviewed as part of https://reviews.llvm.org/D98573
|
|
This reverts a large chunk of http://reviews.llvm.org/D15862 ,
and also fixes bugs in `insert`, `append`, and `assign`, which are now regression-tested.
(Thanks to Tim Song for pointing out the bug in `append`!)
Before this patch, we did a special dance in `append`, `assign`, and `insert`
(but not `replace`). All of these require the strong exception guarantee,
even when the user-provided InputIterator might have throwing operations.
The naive way to accomplish this is to construct a temporary string and
then append/assign/insert from the temporary; i.e., finish all the potentially
throwing and self-inspecting InputIterator operations *before* starting to
modify self. But this is slow, so we'd like to skip it when possible.
The old code (D15682) attempted to check that specific iterator operations
were nothrow: it assumed that if the iterator operations didn't throw, then
it was safe to iterate the input range multiple times and therefore it was
safe to use the fast-path non-naive version. This was wrong for two reasons:
(1) the old code checked the wrong operations (e.g. checked noexceptness of `==`,
but the code that ran used `!=`), and (2) the conversion of value_type to char
could still throw, or inspect the contents of self.
The new code is much simpler, although still much more complicated than it
really could be. We'll likely revisit this codepath at some point, but for now
this patch suffices to get it passing all the new regression tests.
The added tests all fail before this patch, and succeed afterward.
See https://quuxplusone.github.io/blog/2021/04/17/pathological-string-appends/
Differential Revision: https://reviews.llvm.org/D98573
|
|
|
|
These tests were only being run when _LIBCPP_DEBUG was defined, which
isn't the case by default when we run the test suite. In other words,
all these debug mode tests were never being run. This commit makes sure
they are run, and in some cases, extracts them into a file under test/libcxx
to separate them from the Standard tests.
Differential Revision: https://reviews.llvm.org/D88836
|
|
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
|
|
The libc++ test suite has a lot of old Lit features used to XFAIL tests
and mark them as UNSUPPORTED. Many of them are to workaround problems on
old compilers or old platforms. As time goes by, it is good to go and
clean those up to simplify the configuration of the test suite, and also
to reflect the testing reality. It's not useful to have markup that gives
the impression that e.g. clang-3.3 is supported, when we don't really
test on it anymore (and hence several new tests probably don't have the
necessary markup on them).
|
|
The testing script used to test libc++ historically did not like directories
without any testing files, so these tests had been added. Since this is
not necessary anymore, we can now remove these files. This has the benefit
that the total number of tests reflects the real number of tests more
closely, and we also skip some unnecessary work (especially relevant when
running tests over SSH).
However, some nothing_to_do.pass.cpp tests actually serve the purpose of
documenting that an area of the Standard doesn't need to be tested, or is
tested elsewhere. These files are not removed by this commit.
Removal done with:
import os
import itertools
for (dirpath, dirnames, filenames) in itertools.chain(os.walk('./libcxx/test'),
os.walk('./libcxxabi/test')):
if len(filenames + dirnames) > 1 and \
any(p == 'nothing_to_do.pass.cpp' for p in filenames):
os.remove(os.path.join(dirpath, 'nothing_to_do.pass.cpp'))
|
|
Thanks to Zoe for the (big, but simple) patch. NFC intended.
llvm-svn: 362252
|
|
Those tests fail when linking against a new dylib but running against
macosx10.7. I believe this is caused by a duplicate definition of the
RTTI for exception classes in libc++.dylib and libc++abi.dylib, but
this matter still needs some investigation.
This issue was not caught previously because all the tests always linked
against the same dylib used for running (because LIT made it impossible
to do otherwise before r349171).
rdar://problem/46809586
llvm-svn: 354940
|
|
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
|
|
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
|
|
llvm-svn: 336132
|
|
test/std/numerics/numeric.ops/exclusive.scan/exclusive_scan.pass.cpp
test/std/numerics/numeric.ops/exclusive.scan/exclusive_scan_init_op.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan_op.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan_op_init.pass.cpp
test/std/numerics/numeric.ops/transform.exclusive.scan/transform_exclusive_scan_init_bop_uop.pass.cpp
test/std/numerics/numeric.ops/transform.inclusive.scan/transform_inclusive_scan_bop_uop.pass.cpp
test/std/numerics/numeric.ops/transform.inclusive.scan/transform_inclusive_scan_bop_uop_init.pass.cpp
Fix MSVC x64 truncation warnings.
warning C4267: conversion from 'size_t' to 'int', possible loss of data
test/std/strings/basic.string/string.modifiers/string_append/push_back.pass.cpp
Fix MSVC uninitialized memory warning.
warning C6001: Using uninitialized memory 'vl'.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/PR20855_tuple_ref_binding_diagnostics.pass.cpp
Include <cassert> for the assert() macro.
Fixes D43273.
llvm-svn: 326120
|
|
sizeof(T)>sizeof(long long)'. We were mishandling the small-string optimization calculations for very large 'characters'. This may be an ABI change (change the size of) strings of very large 'characters', but since they never worked, I'm not too concerned.
llvm-svn: 324531
|
|
commented it out.
llvm-svn: 319693
|
|
llvm-svn: 319687
|
|
llvm-svn: 314258
|
|
llvm-svn: 312690
|
|
llvm-svn: 309464
|
