aboutsummaryrefslogtreecommitdiff
path: root/libcxx/src/string.cpp
AgeCommit message (Collapse)AuthorFilesLines
11 days[libc++] Refactor memory allocation in basic_string (#128423)Nikolas Klauser1-16/+4
This patch introduces a string-internal API to make the allocation and deallocation the long string simpler. Before this we had a lot of code duplication, so ensuring that things were actually correct was non-trivial.
2025-05-28Revert "[libc++] Introduce ABI sensitive areas to avoid requiring ↵James Y Knight1-2/+0
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756) This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521. Unfortunately, this use of hidden visibility attributes causes user-defined specializations of standard-library types to also be marked hidden by default, which is incorrect. See discussion thread on #131156. ...and also reverts the follow-up commits: Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)" This reverts commit 3e4c9dc299c35155934688184319d391b298fff7. Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)" This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5. Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)" This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
2025-05-18[libc++] Introduce ABI sensitive areas to avoid requiring ↵Nikolas Klauser1-0/+2
_LIBCPP_HIDE_FROM_ABI everywhere (#131156) This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`, which allow us to have implicit annotations for most functions, and just where it's not "hide_from_abi everything" we add explicit annotations. This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most functions in libc++.
2025-04-25[libc++][NFC] Refactor string's extern template lists (#137264)Nikolas Klauser1-1/+1
This patch moves the functions common between our two extern template lists into a common list and avoids some unnecessary _Uglification. This makes the code a lot nicer to read and makes the differences between the two lists obvious.
2025-02-15[libc++] Move unused basic_string function definition to the dylib sources ↵Nikolas Klauser1-0/+38
(#126219) `__init(const value_type*, size_type, size_type)` is part of our ABI, but we don't actually use the function anymore in the dylib. THis moves the definition to the `src/` directory to make it clear that the code is unused. This also allows us to remove it entirely in the unstable ABI.
2024-11-06[libc++] Refactor the configuration macros to being always defined (#112094)Nikolas Klauser1-13/+13
This is a follow-up to #89178. This updates the `<__config_site>` macros.
2024-09-11[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] ↵Nikolas Klauser1-2/+2
(#80455) `[[__noreturn__]]` is now always available, so we can simply use the attribute directly instead of through a macro.
2023-12-18[libc++] Format the code base (#74334)Louis Dionne1-201/+167
This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-07-24[libc++][hardening] Categorize more assertions.varconst1-1/+1
Differential Revision: https://reviews.llvm.org/D155873
2023-07-17[libc++] Use _LIBCPP_VERBOSE_ABORT in a few remaining __throw_FOO functionsLouis Dionne1-13/+2
This provides better error messages when the program terminates due to an exception being thrown in -fno-exceptions mode. Those seem to have been missed in https://reviews.llvm.org/D141222. Differential Revision: https://reviews.llvm.org/D154995
2023-06-28[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.varconst1-1/+1
Replace most uses of `_LIBCPP_ASSERT` with `_LIBCPP_ASSERT_UNCATEGORIZED`. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816
2023-02-17[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONSNikolas Klauser1-1/+1
Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`. Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits, smeenai Differential Revision: https://reviews.llvm.org/D143163
2022-09-06[libc++] Avoid instantiating type_trait classesNikolas Klauser1-2/+2
Use `using` aliases to avoid instantiating lots of types Reviewed By: ldionne, #libc Spies: libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D132785
2022-05-24[libc++][NFC] Whitespace refactoring of string.cpp for consistency and ↵Louis Dionne1-192/+84
legibility
2022-05-24[libc++][NFC] Move definitions around in string.cpp to reduce ↵Louis Dionne1-57/+43
_LIBCPP_HAS_NO_WIDE_CHARACTERS blocks
2022-02-16[libc++] Move everything related solely to _LIBCPP_ASSERT to its own fileLouis Dionne1-1/+1
This is the first step towards disentangling the debug mode and assertions in libc++. This patch doesn't make any functional change: it simply moves _LIBCPP_ASSERT-related stuff to its own file so as to make it clear that libc++ assertions and the debug mode are different things. Future patches will make it possible to enable assertions without enabling the debug mode. Differential Revision: https://reviews.llvm.org/D119769
2022-02-15[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.Arthur O'Dwyer1-8/+8
Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left `#include "include/x.h"` and `#include "../y.h"` alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561
2022-02-03[libc++] Remove the std::string base classNikolas Klauser1-5/+16
Removing the base class of std::basic_string is not an ABI break, so we can remove any references to it from the header. Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D118733
2022-01-25[libc++] Remove std::basic_string's base class in ABIv2Nikolas Klauser1-0/+2
Remove `std::basic_string`'s base class in ABI version 2 Reviewed By: Quuxplusone, ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D116334
2021-11-17[runtimes][NFC] Remove filenames at the top of the license noticeLouis Dionne1-1/+1
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
2021-10-12[libc++] Add an option to disable wide character support in libc++Louis Dionne1-6/+38
Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-10-05[libc++] Refactor how basic_string and vector hoist exception-throwing functionsLouis Dionne1-1/+7
In basic_string and vector, we've been encapsulating all exception throwing code paths in helper functions of a base class, which are defined in the compiled library. For example, __vector_base_common defines two methods, __throw_length_error() and __throw_out_of_range(), and the class is externally instantiated in the library. This was done a long time ago, but after investigating, I believe the goal of the current design was to: 1. Encapsulate the code to throw an exception (which is non-trivial) in an externally-defined function so that the important code paths that call it (e.g. vector::at) are free from that code. Basically, the intent is for the "hot" code path to contain a single conditional jump (based on checking the error condition) to an externally-defined function, which handles all the exception-throwing business. 2. Avoid defining this exception-throwing function once per instantiation of the class template. In other words, we want a single copy of __throw_length_error even if we have vector<int>, vector<char>, etc. 3. Encapsulate the passing of the container-specific string (i.e. "vector" and "basic_string") to the underlying exception-throwing function so that object files don't contain those duplicated string literals. For example, we'd like to have a single "vector" string literal for passing to `std::__throw_length_error` in the library, instead of having one per translation unit. However, the way this is achieved right now has two problems: - Using a base class and exporting it is really weird - I've been confused about this ever since I first saw it. It's just a really unusual way of achieving the above goals. Also, it's made even worse by the fact that the definitions of __throw_length_error and __throw_out_of_range appear in the headers despite always being intended to be defined in the compiled library (via the extern template instantiation). - We end up exporting those functions as weak symbols, which isn't great for load times. Instead, it would be better to export those as strong symbols from the library. This patch fixes those issues while retaining ABI compatibility (e.g. we still export the exact same symbols as before). Note that we need to keep the base classes as-is to avoid breaking the ABI of someone who might inherit from std::basic_string or std::vector. Differential Revision: https://reviews.llvm.org/D111173
2021-06-29[libc++] NFC: Fix return-by-const-value and pass-by-const-value typosLouis Dionne1-1/+1
While we can debate on the value of passing by const value, there is no arguing that it's confusing to do so in some circumstances, such as when marking a pointer parameter as being const (did you mean a pointer-to-const?). This commit fixes a few issues along those lines.
2021-06-09[libc++] Fix libc++ build with assertions enabledLouis Dionne1-3/+3
This fixes http://llvm.org/PR50534. This is another take on D103960 which is less disruptive. Differential Revision: https://reviews.llvm.org/D103964
2020-03-02Add flag _LIBCPP_ABI_STRING_OPTIMIZED_EXTERNAL_INSTANTIATIONS for ↵Martijn Vels1-1/+1
basic_string ABI Summary: This review is a mostly trivial change to use an explicit ABI flag for the unstable external template list. This follows the practice for an ABI flag per feature, and provides a spot for the rational / motivation for the flag. Reviewers: EricWF, ldionne Subscribers: dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D75457
2020-02-20Split _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a V1 and UNSTABLE version.Martijn Vels1-2/+7
This change splits the _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a _LIBCPP_STRING_V1_EXTERN_TEMPLATE_LIST containing the stable ABI, and a _LIBCPP_STRING_UNSTABLE_EXTERN_TEMPLATE_LIST containing the unstable ABI. The purpose is to explicitly define and maintain the two lists, where the unstable ABI allows for ABI breaking changes for purposes such as optimization while offering a strong guarantee that any change inside the unstable ABI does not affect the stable ABI. As per the comment in the __string header, we do still allow etries to be added to the stable ABI list as the c++ versions and corresponding c++ std API changes.
2020-01-15[libc++] Explicitly enumerate std::string external instantiations - Attempt 2Eric Fiselier1-2/+2
The GCC build failures have been addressed, and the LLDB failures were fixed by LLDB. I have also verified that the apple-clang 9.0 segfault no longer occurs. Original Message: The external instantiation of std::string is a problem for libc++. Additions and removals of inline functions in string can cause ABI breakages, including introducing new symbols. This patch aims to: (1) Make clear which functions are explicitly instatiated. (2) Prevent new functions from being accidentally instantiated. (3) Allow a migration path for adding or removing functions from the explicit instantiation over time. Although this new formulation is uglier, it is preferable from a maintainability and readability standpoint because it explicitly enumerates the functions we've chosen to expose in our ABI. Changing this list is non-trivial and requires thought and planning. (3) is achieved by making it possible to control the extern template declaration separately from it's definition. Meaning we could add a new definition to the dylib, wait for it to roll out, then add the extern template declaration to the header. Similarly, we could remove existing extern template declarations while still keeping the definition to prevent ABI breakages.
2020-01-13Revert "[libc++] Explicitly enumerate std::string external instantiations."Oliver Stannard1-2/+2
This is causing failures for multiple buildbots and bootstrap builds, details at https://reviews.llvm.org/rG61bd1920. This reverts commit 61bd19206f61ace4b007838a2ff8884a13ec0374.
2020-01-09[libc++] Explicitly enumerate std::string external instantiations.Eric Fiselier1-2/+2
The external instantiation of std::string is a problem for libc++. Additions and removals of inline functions in string can cause ABI breakages, including introducing new symbols. This patch aims to: (1) Make clear which functions are explicitly instatiated. (2) Prevent new functions from being accidentally instantiated. (3) Allow a migration path for adding or removing functions from the explicit instantiation over time. Although this new formulation is uglier, it is preferable from a maintainability and readability standpoint because it explicitly enumerates the functions we've chosen to expose in our ABI. Changing this list is non-trivial and requires thought and planning. (3) is achieved by making it possible to control the extern template declaration separately from it's definition. Meaning we could add a new definition to the dylib, wait for it to roll out, then add the extern template declaration to the header. Similarly, we could remove existing extern template declarations while still keeping the definition to prevent ABI breakages.
2019-06-10Recommit r362649, which was reverted in r262680 because of bugs in ↵Marshall Clow1-103/+37
std::to_chars (which have now been fixed). Speedup to_string and to_wstring for integers using stack buffer and SSO llvm-svn: 363003
2019-06-06Revert "Speedup to_string and to_wstring for integers using stack buffer and ↵Vlad Tsyrklevich1-37/+103
SSO." This reverts commit 7ce7110e6d964778141c0866488e154b1ce73d69, it was causing sanitizer bot failures due to changing behavior of std::to_string(). See https://reviews.llvm.org/D59178#1532023 llvm-svn: 362680
2019-06-05Speedup to_string and to_wstring for integers using stack buffer and SSO. ↵Marshall Clow1-103/+37
Reviewed as https://reviews.llvm.org/D59178 Thanks to ivafanas for all his work on this patch. llvm-svn: 362649
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2017-05-10[libc++] Refactor Windows support headers.Eric Fiselier1-4/+1
Summary: This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers. The changes in this patch are: * remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers. * Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles. * Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang. I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check? This refactor is needed to support upcoming fixes to `<locale>` on Windows. Reviewers: bcraig, rmaprath, compnerd, EricWF Reviewed By: EricWF Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D32988 llvm-svn: 302727
2016-10-14Revert r284193 - it is not correct on OS XEric Fiselier1-3/+0
llvm-svn: 284194
2016-10-14Re-export two previously exported std::string functions.Eric Fiselier1-0/+3
These functions were removed from the dylib sometime between the 3.9 release and now. This patch manually exports them to re-gain ABI compatibility. llvm-svn: 284193
2016-10-13Revert r282345 - Use __attribute__((internal_linkage)) when available.Eric Fiselier1-23/+0
llvm-svn: 284101
2016-09-25Use __attribute__((internal_linkage)) when available.Eric Fiselier1-0/+23
Summary: This patch has been a long time coming (Thanks @eugenis). It changes `_LIBCPP_INLINE_VISIBILITY` to use `__attribute__((internal_linkage))` instead of `__attribute__((visibility("hidden"), always_inline))`. The point of `_LIBCPP_INLINE_VISIBILITY` is to prevent inline functions from being exported from both the libc++ library and from user libraries. This helps libc++ better manage it's ABI. Previously this was done by forcing inlining and modifying the symbols visibility. However inlining isn't guaranteed and symbol visibility only affects shared libraries making this an imperfect solution. `internal_linkage` improves this situation by making all symbols local to the TU they are emitted in, regardless of inlining or visibility. IIRC the effect of applying `__attribute__((internal_linkage))` to an inline function is the same as applying `static`. For more information about the attribute see: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html Most of the work for this patch was done by @eugenis. Reviewers: mclow.lists, eugenis Subscribers: eugenis, cfe-commits Differential Revision: https://reviews.llvm.org/D24642 llvm-svn: 282345
2016-09-19[libc++] Fix extern template visibility for WindowsShoaib Meenai1-3/+3
On Windows, marking an `extern template class` declaration as exported actually forces an instantiation, which is not the desired behavior. Instead, the actual explicit instantiations need to be exported. Differential Revision: https://reviews.llvm.org/D24679 llvm-svn: 281925
2016-08-25Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception ↵Marshall Clow1-1/+1
type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these functions everywhere instead of assert()ing when exceptions are disabled. WARNING: This is a behavior change - but only with exceptions disabled. Reviewed as: https://reviews.llvm.org/D23855. llvm-svn: 279744
2015-03-10Print log/error messages on stderr, not stdoutEd Schouten1-1/+1
There are a couple of places where libc++ prints log/error messages to stdout on its own. This may of course interfere with the output generated with applications. Log/error messages should be directed to stderr instead. Differential Revision: http://reviews.llvm.org/D8135 Reviewed by: marshall llvm-svn: 231767
2014-11-14Initialize pointer in string conversion helpers to prevent MSAN diagnostic.Eric Fiselier1-2/+2
Since the initialization of the pointer happens across the libc library boundry MSAN will not know the pointer was initialized. This fixes MSAN failures in test/strings/string.conversions. llvm-svn: 222052
2014-08-15Revert "Turn off extern templates for most uses."Justin Bogner1-2/+0
Turning off explicit template instantiation leads to a pretty significant build time and code size cost. We're better off dealing with ABI incompatibility issues that come up in a less heavy handed way. This reverts commit r189610. llvm-svn: 215740
2013-09-17Fix typo.Joerg Sonnenberger1-1/+1
llvm-svn: 190857
2013-08-29Turn off extern templates for most uses. It is causing more problems than ↵Howard Hinnant1-0/+2
it is worth. The extern templates will still be built into the dylib, mainly for ABI stability purposes. And the client can still turn these back on with a #define if desire. This fixes http://llvm.org/bugs/show_bug.cgi?id=17027. However there's no associated test for the test suite because http://llvm.org/bugs/show_bug.cgi?id=17027 needs mismatched dylib and headers to fire. llvm-svn: 189610
2013-08-01Nico Rieck: Currently _MSC_VER and _WIN32 are used to guard code which isHoward Hinnant1-3/+3
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can also define _MSC_VER, and MSVCRT is not necessarily the only C runtime, these macros should not be used interchangeably. This patch divides all Windows-related bits into the aforementioned categories. Two new macros are introduced: - _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using _MSC_VER, excluding Clang. - _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default when _WIN32 is defined. This leaves _WIN32 for code using the Windows API. This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF. Nico, please prepare a patch for CREDITS.TXT, thanks. llvm-svn: 187593
2013-07-23Add some friendly messages to libcxx calls to abort().Howard Hinnant1-0/+2
llvm-svn: 186951
2013-05-16Glen: This patch gets the string conversion functions working on Windows. ↵Howard Hinnant1-489/+328
It also refactors repetitive code in string.cpp do greatly reduce the repetitiveness, increasing maintainability. llvm-svn: 182026
2013-03-18Removed raw references to _WIN32; now just check to see if it is defined.Marshall Clow1-1/+1
llvm-svn: 177291
2013-01-22Saleem Abdulrasool: If errno is defined as volatile int, the qualifier ↵Howard Hinnant1-16/+16
differences can cause template typename deductions on swap<> (used in string.cpp). Use decltype(errno) to replicate the type and qualifier information for holding the errno value. Because errno is expected to be assignable, there is no need to use typename std::remove_const<decltype(errno)>::type to hold the value. llvm-svn: 173172
generated by cgit v1.1 at 2025-09-29 06:55:26 +0000