aboutsummaryrefslogtreecommitdiff
path: root/libcxx/src
AgeCommit message (Collapse)AuthorFilesLines
2023-09-19[libc++][NFC] Clean up std::__call_onceDaniel McIntosh1-40/+25
__call_once is large and cluttered with #ifdef preprocessor guards. This cleans it up a bit by using an exception guard instead of try-catch. Differential Revision: https://reviews.llvm.org/D112319 Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2023-09-15[libc++][NFC] Introduce named states in std::call_once (#66289)Louis Dionne1-9/+9
This idea is extracted from https://reviews.llvm.org/D112319. It makes the code easier to read but doesn't otherwise change any functionality.
2023-09-12[libc++] Simplify the implementation of locale::id (#65781)Louis Dionne1-29/+2
Since we use C++20 to build the dylib, we can use a lambda to do the first-time initialization instead of emulating std::bind. This should not change the behavior of the code at all, it merely simplifies it. This removes a symbol from the dylib, however that symbol was only ever used inside the dylib so it shouldn't break the ABI for anyone. I confirmed that by searching for that symbol on the ABI boundary of a large number of programs and couldn't find any references to that function.
2023-09-11[libc++] Mark static variables of locale::id as constinit (#65783)Louis Dionne1-11/+11
The dylib contains multiple global variables of type locale::id. Those can be marked as constinit to make it clear that static initialization is performed.
2023-09-10[libc++] Use inline instead of static in headers.Mark de Wever1-6/+6
This has been tested as part of D156609.
2023-09-08[libc++] Fix warnings when compiling libc++ for Windows with clang-cl /W4Colin Finck2-3/+3
Differential Revision: https://reviews.llvm.org/D96408
2023-09-08[libc++][NFC] tidy up strstreambuf::seekoff and strstreambuf::seekposDaniel McIntosh1-57/+56
Should be the same logic, but hopefully easier to read this way. Gets rid of some superfluous state variables, and uses early returns. Differential Revision: https://reviews.llvm.org/D112956
2023-09-08[libc++][NFC] Run clang-format on strstream.cppLouis Dionne1-262/+181
I'm about to land https://reviews.llvm.org/D112956 which touches many lines in that file anyway, so we might as well clang-format it first.
2023-09-06[libc++][chrono] Adds tzdb_list implementation.Mark de Wever3-0/+266
This is the first step to implement time zone support in libc++. This adds the complete tzdb_list class and a minimal tzdb class. The tzdb class only contains the version, which is used by reload_tzdb. Next to these classes it contains documentation and build system support needed for time zone support. The code depends on the IANA Time Zone Database, which should be available on the platform used or provided by the libc++ vendors. The code is labeled as experimental since there will be ABI breaks during development; the tzdb class needs to have the standard headers. Implements parts of: - P0355 Extending <chrono> to Calendars and Time Zones Addresses: - LWG3319 Properly reference specification of IANA time zone database Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D154282
2023-09-06[libc++] Remove unused include in __threading_supportLouis Dionne1-0/+2
Differential Revision: https://reviews.llvm.org/D138528
2023-09-05[libc++] Avoid destructor call for error_category singletonsChris Bowler5-43/+67
When a handle to an error_category singleton object is used during the termination phase of a program, the destruction of the error_category object may have occurred prior to execution of the current destructor or function registered with atexit, because the singleton object may have been constructed after the corresponding initialization or call to atexit. For example, the updated tests from this patch will fail if using a libc++ built using a compiler that updates the vtable of the object on destruction. This patch attempts to avoid the issue by causing the destructor to not be called in the style of ResourceInitHelper in src/experimental/memory_resource.cpp. This approach might not work if object lifetime is strictly enforced. Differential Revision: https://reviews.llvm.org/D65667 Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2023-08-29[libc++][hardening] Mark the remaining stray assertions as uncategorizedKonstantin Varlamov1-2/+2
This avoids enabling them unconditionally in all hardening modes. Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D158970
2023-08-29[libc++] Adds __throw_system_error overload.Mark de Wever2-14/+3
This was mention in D150044 and D154995 that this would be useful. This addresses the last review coment of D150044. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D156019
2023-08-25[libc++] Fix GNU/Hurd buildSamuel Thibault2-2/+2
GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete. Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D158584
2023-08-18[libc++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylibLouis Dionne8-18/+18
Since we build the dylib with C++20, there's no need to use conditional macros anymore. Differential Revision: https://reviews.llvm.org/D157995
2023-08-15[libc++][PSTL] Add a __parallel_sort implementation to libdispatchNikolas Klauser1-0/+2
Reviewed By: #libc, ldionne Spies: ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D155136
2023-08-14[libc++][PSTL] Simplify the partitioning algorithm until we have better data ↵Nikolas Klauser1-42/+3
to know how to chunk better The current chunking strategy is very bad for sorting, and we don't really know how to chunk in general. This fixes the performance problem for sorting. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski Differential Revision: https://reviews.llvm.org/D155531
2023-08-11[libc++] Optimize internal function in <system_error>Edoardo Sanguineti1-20/+26
In the event the internal function __init is called with an empty string the code will take unnecessary extra steps, in addition, the code generated might be overall greater because, to my understanding, when initializing a string with an empty `const char*` "" (like in this case), the compiler might be unable to deduce the string is indeed empty at compile time and more code is generated. The goal of this patch is to make a new internal function that will accept just an error code skipping the empty string argument. It should skip the unnecessary steps and in the event `if (ec)` is `false`, it will return an empty string using the correct ctor, avoiding any extra code generation issues. After the conversation about this patch matured in the libcxx channel on the LLVM Discord server, the patch was analyzed quickly with "Compiler Explorer" and other tools and it was discovered that it does indeed reduce the amount of code generated when using the latest stable clang version (16) which in turn produces faster code. This patch targets LLVM 18 as it will break the ABI by addressing https://github.com/llvm/llvm-project/issues/63985 Benchmark tests run on other machines as well show in the best case, that the new version without the extra string as an argument performs 10 times faster. On the buildkite CI run it shows the new code takes less CPU time as well. In conclusion, the new code should also just appear cleaner because there are fewer checks to do when there is no message. Reviewed By: #libc, philnik Spies: emaste, nemanjai, philnik, libcxx-commits Differential Revision: https://reviews.llvm.org/D155820
2023-08-10[libc++] Use _LIBCPP_VERBOSE_ABORT from __throw_bad_allocLouis Dionne1-2/+2
It seems like this one was forgotten and we were still using a raw std::abort(). Differential Revision: https://reviews.llvm.org/D157446
2023-08-10[libc++] Clean up mess around __throw_runtime_errorLouis Dionne2-59/+45
We were defining the function in locale.cpp, and we actually had two overloads for it. This is pretty confusing given that one was static and not exported from the dylib, and the other one was. Instead, use the vanilla __throw_runtime_error function everywhere even though that adds a tiny bit of code duplication. Differential Revision: https://reviews.llvm.org/D155008
2023-07-24[libc++][hardening] Categorize more assertions.varconst1-1/+1
Differential Revision: https://reviews.llvm.org/D155873
2023-07-20[libc++] Make sure we use the libdispatch backend on Apple platformsLouis Dionne1-5/+6
The Apple.cmake cache wasn't set up properly, so we wouldn't enable the libdispatch backend by default on Apple platforms. This patch fixes the issue and adds a test. We also need to make various drive-by fixes: - Drop the usage of std::vector in libdispatch.h to avoid changing the transitive includes only on Apple platforms. - Fix includes - Use __construct at since construct_at is unavailable in C++17 - Get rid of the (unused) __get_memory_resource function since that adds a back-deployment requirement and we don't use it right now. - Fix bugs in the chunking logic around boundary conditions. Differential Revision: https://reviews.llvm.org/D155649
2023-07-18[libc++][print] Adds FILE functions.Mark de Wever2-0/+63
Drive-by fix to make sure the __retarget_buffer works correctly whan using a hint of 1. This was discovered in one of the new tests. Drive-by fixes __retarget_buffer when initialized with size 1. Implements parts of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D150044
2023-07-17[libc++] Use _LIBCPP_VERBOSE_ABORT in a few remaining __throw_FOO functionsLouis Dionne3-20/+7
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-07-17[libc++] Remove internal "build-with-external-thread-library" configurationLouis Dionne1-21/+0
Our threading support layer is currently a huge mess. There are too many configurations with too many confusing names, and none of them are tested in the usual CI. Here's a list of names related to these configurations: LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL This patch cleans this up by removing the ability to build libc++ with an "external" threading library for testing purposes, removing 4 out of 6 "names" above. That setting was meant to be used by libc++ developers, but we don't use it in-tree and it's not part of our CI. I know the ability to use an external threading API is used by some folks out-of-tree, and this patch doesn't change that. This only changes the way they will have to test their external threading support. After this patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON` when building the library, and to provide their usual `<__external_threading>` header when they are testing the library. This can be done easily now that we support custom lit configuration files in test suites. The motivation for this patch is that our threading support layer is basically unmaintainable -- anything beyond adding a new "backend" in the slot designed for it requires incredible attention. The complexity added by this setting just doesn't pull its weigh considering the available alternatives. Concretely, this will also allow future patches to clean up `<__threading_support>` significantly. Differential Revision: https://reviews.llvm.org/D154466
2023-07-13[libc++] Fix filesystem tests on platforms that don't have IOLouis Dionne1-1/+3
This patch moves a few tests that were still using std::fprintf to using TEST_REQUIRE instead, which provides a single point to tweak for platforms that don't implement fprintf. As a fly-by fix, it also avoids including `time_utils.h` in filesystem_clock.cpp when it is not required, since that header makes some pretty large assumptions about the platform it is on. Differential Revision: https://reviews.llvm.org/D155019
2023-07-13[gn build] Port 2b2e7f6e5727Nico Weber1-1/+3
2023-07-12[libc++] Fix clock selection in chrono.cpp and filesystem_clock.cppLouis Dionne2-8/+8
This patch partly reverts the change that was made in 5f1ba3a502 regarding the clock selection on Apple platforms. It turns out that gettimeofday() is marked as obsolete by POSIX and clock_gettime() is recommended instead. Since both are equivalent for our purposes, prefer using clock_gettime() even on Apple platforms. Differential Revision: https://reviews.llvm.org/D155022
2023-07-12[libc++][PSTL] Add a GCD backendNikolas Klauser2-0/+75
Reviewed By: ldionne, #libc Spies: arichardson, mgrang, krytarowski, libcxx-commits, h-vetinari Differential Revision: https://reviews.llvm.org/D151717
2023-07-11[libc++] Move __thread_id out of <__threading_support>Louis Dionne1-0/+1
This makes <__threading_support> closer to handling only the bridge between the system's implementation of threading and the rest of libc++. Differential Revision: https://reviews.llvm.org/D154464
2023-07-08[libc++] Fix simple cases of locale name constructionJake Egan1-4/+14
When using the following constructors: ``` locale(const locale& other, const char* std_name, category cat); locale(const locale& other, const string& std_name, category cat); locale(const locale& other, const locale& one, category cats); ``` The new locale name is always "*". Locale names formed from parts of two named locales (that is, C++ locales having names) are supposed to have names in turn (see C++20 subclause 28.3.1.1 [locale.general] paragraph 8). This patch fixes the name construction for cases when either of locales are unnamed, when the category is locale::none, and when the two locale names are the same. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D119441
2023-07-07[libc++] Make sure we use __ulock on Apple platformsLouis Dionne1-0/+2
We forgot to include the header, which means that _LIBCPP_USE_ULOCK was always undefined and we'd always use the fallback. Note that this doesn't seem to fix https://github.com/llvm/llvm-project/issues/63737. Differential Revision: https://reviews.llvm.org/D154718
2023-07-05[libcxx] Migrate posix_compat.h layer to not use CRT filesystem functions.James Y Knight2-11/+53
Right now, the filesystem APIs _mostly_ use Win32 API calls, but a small number of functions use CRT APIs instead. The semantics are effectively the same, except for which sorts of error codes are returned. We want to be consistent about returning only native Win32 error codes, as a prerequisite for https://reviews.llvm.org/D151493. This change switches getcwd, chdir, and mkdir. It does _not_ switch open/close, because there are difficulties around the use of C-runtime file descriptor numbers. Instead, those two APIs are removed from posix_compat.h, and the win32-specific code inlined into the operations.cpp FileDescriptor class (with a TODO comment). Reviewed By: #libc, mstorsjo, Mordante Differential Revision: https://reviews.llvm.org/D153037
2023-07-05[libc++] Synchronize clock selection between chrono.cpp and filesystem_clock.cppLouis Dionne2-5/+13
Note that _FilesystemClock will now be implemented by calling gettimeofday() on Apple platforms instead of clock_gettime(). However, since both are equivalent, this should not change the behavior on Apple platforms. There should be no behavior change on other platforms. In addition to being a consistency clean up, this fixes some issues seen by folks as reported in https://reviews.llvm.org/D154390#4471924. Differential Revision: https://reviews.llvm.org/D154457
2023-07-04[libc++] Avoid including things that require a filesystem in filesytem_clock.cppLouis Dionne4-79/+85
The filesystem clock implementation should be available regardless of whether a proper filesystem is available on the platform, so it makes sense to try and avoid including things that are inherently filesystem-y in the implementation of filesystem clock. Differential Revision: https://reviews.llvm.org/D154390
2023-07-04[libc++][NFC] clang-format <shared_mutex>Louis Dionne1-75/+54
I am about to touch several lines in that file for a patch anyway, so I might as well clang-format it upfront to avoid mixing styles after my patch.
2023-06-29[libc++] Remove the legacy debug mode.varconst3-567/+0
See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026 Reviewed By: #libc, Mordante, ldionne Differential Revision: https://reviews.llvm.org/D153672
2023-06-29[libc++] Stop using __builtin_assume in _LIBCPP_ASSERTLouis Dionne1-1/+1
__builtin_assume can sometimes worsen code generation. For now, the guideline seems to be to avoid adding assumptions without a clear optimization intent. Since _LIBCPP_ASSERT is very general, we can't have a clear optimization intent at this level, which makes __builtin_assume the wrong tool for the job -- at least until __builtin_assume is changed. See https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609 for a discussion of this. Differential Revision: https://reviews.llvm.org/D153968
2023-06-28[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.varconst17-61/+62
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-06-27[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEMLouis Dionne1-4/+4
Since LIBCXX_ENABLE_FILESYSTEM now truly represents whether the platform supports a filesystem (as opposed to whether the <filesystem> library is provided), we can provide a few additional classes from the <filesystem> library even when the platform does not have support for a filesystem. For example, this allows performing path manipulations using std::filesystem::path even on platforms where there is no actual filesystem. rdar://107061236 Differential Revision: https://reviews.llvm.org/D152382
2023-06-26[libc++][filesystem] Avoid using anonymous namespaces in support headersLouis Dionne7-131/+70
This avoids using anonymous namespaces in headers and ensures that the various helper functions get deduplicated across the TUs implementing <filesystem>. Otherwise, we'd get a definition of these helper functions in each TU where they are used, which is entirely unnecessary. Differential Revision: https://reviews.llvm.org/D152378
2023-06-21[libcxx] Include <sys/time.h> in posix_compat.hPetr Hosek1-0/+1
posix_compat.h uses struct timeval which is defined in <sys/time.h> but it doesn't include it. On most POSIX platforms like Linux or macOS, that headers is transitively included by other headers like <sys/stat.h>, but there are other platforms where this is not the case. Differential Revision: https://reviews.llvm.org/D153384
2023-06-21[libc++] Get rid of _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONSLouis Dionne2-5/+8
Whether we include operator new and delete into libc++ has always been a build time setting, and piggy-backing on a macro like _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS is inconsistent with how we handle similar cases for e.g. LIBCXX_ENABLE_RANDOM_DEVICE. Instead, simply avoid including new.cpp in the sources of the library when we do not wish to include these operators in the build. This also makes us much closer to being able to share the definitions between libc++ and libc++abi, since we could technically build those definitions into a standalone static library and decide whether we link it into libc++abi.dylib or libc++.dylib. Differential Revision: https://reviews.llvm.org/D153272
2023-06-19[libc++] Move non operator new definitions outside of new.cppLouis Dionne3-23/+31
This makes it such that new.cpp contains only the definitions of operator new and operator delete, like its libc++abi counterpart. Differential Revision: https://reviews.llvm.org/D153136
2023-06-19[libc++] Split sources for <filesystem>Louis Dionne13-1451/+1718
The operations.cpp file contained the implementation of a ton of functionality unrelated to just the filesystem operations, and filesystem_common.h contained a lot of unrelated functionality as well. Splitting this up into more files will make it possible in the future to support parts of <filesystem> (e.g. path) on systems where there is no notion of a filesystem. Differential Revision: https://reviews.llvm.org/D152377
2023-06-17[libc++][NFC] Granularise <thread> headerHui2-0/+3
- This was to make implementing jthread easier and requested in https://reviews.llvm.org/D151559 Differential Revision: https://reviews.llvm.org/D151792
2023-06-16[libc++][NFC] Consistently qualify malloc and free calls with std::Louis Dionne1-3/+3
2023-06-16[libc++] Make libc++ and libc++abi's definitions of operator new be exact copiesLouis Dionne1-0/+6
This allows mechanically copying any changes made to `operator new` from libc++ into libc++abi as-is. This is also a step towards de-duplicating this code entirely. Differential Revision: https://reviews.llvm.org/D153035
2023-06-15[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI ↵Nikolas Klauser14-29/+29
into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652
2023-06-15[libc++][NFC] clang-format new_handler.cppLouis Dionne1-18/+10
generated by cgit v1.1 at 2025-09-30 00:42:18 +0000