The capacity is now passed correctly and a test for this path is added. Since we changed the implementation of `reserve(size_type)` to only ever extend, it doesn't make a ton of sense anymore to have `__shrink_or_extend`, since the code paths of `reserve` and `shrink_to_fit` are now almost completely separate. This patch splits up `__shrink_or_extend` so that the individual parts are in `reserve` and `shrink_to_fit` depending on where they are needed. This reverts commit 59f57be94f38758616b1339b293b43af845571af.
This patch removes many annotations that are not relevant anymore since we don't support or test back-deploying to macOS < 10.13. It also cleans up raw usage of target triples to identify versions of dylibs shipped on prior versions of macOS, and uses the target-agnostic Lit features instead. Finally, it reorders both the Lit backdeployment features and the corresponding availability macros in the library in a way that makes more sense, and reformulates the Lit backdeployment features in terms of when a version of LLVM was introduced instead of encoding the system versions on which it hasn't been introduced yet. Although one can be derived from the other, encoding the negative form is extremely error-prone. Fixes #80901
We were not making any distinction between e.g. the "Apple-flavored" libc++ built from trunk and the system-provided standard library on Apple platforms. For example, any test that would be XFAILed on a back-deployment target would unexpectedly pass when run on that deployment target against the tip of trunk Apple-flavored libc++. In reality, that test would be expected to pass because we're running against the latest libc++, even if it is Apple-flavored. To solve this issue, we introduce a new feature that describes whether the Standard Library in use is the one provided by the system by default, and that notion is different from the underlying standard library flavor. We also refactor the existing Lit features to make a distinction between availability markup and the library we're running against at runtime, which otherwise limit the flexibility of what we can express in the test suite. Finally, we refactor some of the back-deployment versions that were incorrect (such as thinking that LLVM 10 was introduced in macOS 11, when in reality macOS 11 was synced with LLVM 11). Fixes #82107
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
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
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
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
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