aboutsummaryrefslogtreecommitdiff
path: root/libcxx/src
AgeCommit message (Collapse)AuthorFilesLines
2022-08-03[libc++] Simplify how we define the linker script for libc++Louis Dionne1-16/+24
Trying to be generic didn't work properly because we had to special-case some interface libraries that we didn't want in the linker script. Instead, only look at the ABI and the unwinding libraries explicitly. This should solve the issue reported by @dim in [1]. [1]: https://discourse.llvm.org/t/15-0-0-rc1-has-been-tagged/64174/22 Differential Revision: https://reviews.llvm.org/D131037
2022-08-02[libcxx] Fixed a number of typosGabriel Ravier1-1/+1
I went over the output of the following mess of a command: `(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)` and proceeded to spend a few days looking at it to find probable typos and fixed a few hundred of them in all of the llvm project (note, the ones I found are not anywhere near all of them, but it seems like a good start). Reviewed By: #libc, philnik Spies: philnik, libcxx-commits, mgorny, arichardson Differential Revision: https://reviews.llvm.org/D130905
2022-07-29[libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abortLouis Dionne2-3/+3
With the goal of reusing that handler to do other things besides handling assertions (such as terminating when an exception is thrown under -fno-exceptions), the name `__libcpp_assertion_handler` doesn't really make sense anymore. Furthermore, I didn't want to use the name `__libcpp_abort_handler`, since that would give the impression that the handler is called whenever `std::abort()` is called, which is not the case at all. Differential Revision: https://reviews.llvm.org/D130562
2022-07-28[libc++] Properly log crashes with the assertion handler on older AndroidsLouis Dionne1-3/+15
This reintroduces the same workaround we have in libc++abi for older Androids based on https://reviews.llvm.org/D130507#inline-1255914. Differential Revision: https://reviews.llvm.org/D130708
2022-07-27[libc++] Implement P1004R2 (constexpr std::vector)Nikolas Klauser1-0/+5
Reviewed By: #libc, ldionne Spies: mgorny, var-const, ormris, philnik, miscco, hiraditya, steven_wu, jkorous, ldionne, christof, libcxx-commits Differential Revision: https://reviews.llvm.org/D68365
2022-07-26[libc++] Generalize the customizeable assertion handlerLouis Dionne1-2/+45
Instead of taking a fixed set of arguments, use variadics so that we can pass arbitrary arguments to the handler. This is the first step towards using the handler to handle other non-assertion-related failures, like std::unreachable and an exception being thrown in -fno-exceptions mode, which would improve user experience by including additional information in crashes (right now, we call abort() without additional information). Differential Revision: https://reviews.llvm.org/D130507
2022-07-19[libc++] Treat incomplete features just like other experimental featuresLouis Dionne1-6/+2
In particular remove the ability to expel incomplete features from the library at configure-time, since this can now be done through the _LIBCPP_ENABLE_EXPERIMENTAL macro. Also, never provide symbols related to incomplete features inside the dylib, instead provide them in c++experimental.a (this changes the symbols list, but not for any configuration that should have shipped). Differential Revision: https://reviews.llvm.org/D128928
2022-07-19[libc++] Re-apply "Always build c++experimental.a""Louis Dionne1-29/+25
This re-applies bb939931a1ad, which had been reverted by 09cebfb978de because it broke Chromium. The issues seen by Chromium should be addressed by 1d0f79558ca4. Differential Revision: https://reviews.llvm.org/D128927
2022-07-19[libc++] Make sure cxx_experimental links against libc++ headersLouis Dionne1-0/+1
This should fix builds where we build neither the static nor the shared library.
2022-07-18Revert "[libc++] Always build c++experimental.a"Hans Wennborg1-24/+28
This caused build failures when building Clang and libc++ together on Mac: fatal error: 'experimental/memory_resource' file not found See the code review for details. Reverting until the problem and how to solve it is better understood. (Updates to some test files were not reverted, since they seemed unrelated and were later updated by 340b48b267b96.) > This is the first part of a plan to ship experimental features > by default while guarding them behind a compiler flag to avoid > users accidentally depending on them. Subsequent patches will > also encompass incomplete features (such as <format> and <ranges>) > in that categorization. Basically, the idea is that we always > build and ship the c++experimental library, however users can't > use what's in it unless they pass the `-funstable` flag to Clang. > > Note that this patch intentionally does not start guarding > existing <experimental/FOO> content behind the flag, because > that would merely break users that might be relying on such > content being in the headers unconditionally. Instead, we > should start guarding new TSes behind the flag, and get rid > of the existing TSes we have by shipping their Standard > counterpart. > > Also, this patch must jump through a few hoops like defining > _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers > that do not implement -funstable yet. > > Differential Revision: https://reviews.llvm.org/D128927 This reverts commit bb939931a1adb9a47a2de13c359d6a72aeb277c8.
2022-07-08[libc++] Always build c++experimental.aLouis Dionne1-28/+24
This is the first part of a plan to ship experimental features by default while guarding them behind a compiler flag to avoid users accidentally depending on them. Subsequent patches will also encompass incomplete features (such as <format> and <ranges>) in that categorization. Basically, the idea is that we always build and ship the c++experimental library, however users can't use what's in it unless they pass the `-funstable` flag to Clang. Note that this patch intentionally does not start guarding existing <experimental/FOO> content behind the flag, because that would merely break users that might be relying on such content being in the headers unconditionally. Instead, we should start guarding new TSes behind the flag, and get rid of the existing TSes we have by shipping their Standard counterpart. Also, this patch must jump through a few hoops like defining _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers that do not implement -funstable yet. Differential Revision: https://reviews.llvm.org/D128927
2022-07-08[libcxx] Make LIBCXX_HERMETIC_STATIC_LIBRARY apply to libc++experimental tooMartin Storsjö1-0/+6
This avoids dllexports in that library. Differential Revision: https://reviews.llvm.org/D129271
2022-06-30[libc++] Implement P0618R0 (Deprecating <codecvt>)Nikolas Klauser1-0/+20
Reviewed By: ldionne, #libc Spies: cfe-commits, llvm-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D127313
2022-06-21[libc++] Improve charconv base10 algorithm.Mark de Wever1-2/+2
This change is a preparation to add the 128-bit integral output. Before ``` -------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------- BM_to_chars_good/2 20.1 ns 20.1 ns 35045000 BM_to_chars_good/3 117 ns 117 ns 5916000 BM_to_chars_good/4 83.7 ns 83.7 ns 8401000 BM_to_chars_good/5 70.6 ns 70.6 ns 9915000 BM_to_chars_good/6 59.9 ns 59.9 ns 11678000 BM_to_chars_good/7 53.9 ns 53.8 ns 12995000 BM_to_chars_good/8 19.0 ns 19.0 ns 37110000 BM_to_chars_good/9 45.9 ns 45.8 ns 15278000 BM_to_chars_good/10 9.24 ns 9.24 ns 75343000 BM_to_chars_good/11 42.6 ns 42.6 ns 16449000 BM_to_chars_good/12 38.8 ns 38.8 ns 18101000 BM_to_chars_good/13 38.8 ns 38.8 ns 17999000 BM_to_chars_good/14 37.7 ns 37.6 ns 18571000 BM_to_chars_good/15 35.8 ns 35.8 ns 19660000 BM_to_chars_good/16 15.4 ns 15.4 ns 46129000 BM_to_chars_good/17 32.3 ns 32.3 ns 21763000 BM_to_chars_good/18 32.8 ns 32.8 ns 21396000 BM_to_chars_good/19 33.4 ns 33.4 ns 21078000 BM_to_chars_good/20 33.3 ns 33.3 ns 21020000 BM_to_chars_good/21 32.3 ns 32.3 ns 21807000 BM_to_chars_good/22 31.6 ns 31.6 ns 22057000 BM_to_chars_good/23 30.7 ns 30.7 ns 22938000 BM_to_chars_good/24 28.3 ns 28.3 ns 24659000 BM_to_chars_good/25 28.2 ns 28.2 ns 24790000 BM_to_chars_good/26 28.4 ns 28.4 ns 24410000 BM_to_chars_good/27 28.7 ns 28.7 ns 24423000 BM_to_chars_good/28 28.9 ns 28.9 ns 24139000 BM_to_chars_good/29 28.9 ns 28.9 ns 24347000 BM_to_chars_good/30 29.2 ns 29.2 ns 24141000 BM_to_chars_good/31 29.6 ns 29.6 ns 23699000 BM_to_chars_good/32 29.5 ns 29.5 ns 23933000 BM_to_chars_good/33 28.9 ns 28.9 ns 24042000 BM_to_chars_good/34 28.7 ns 28.7 ns 24361000 BM_to_chars_good/35 28.3 ns 28.3 ns 24703000 BM_to_chars_good/36 28.1 ns 28.1 ns 24924000 BM_to_chars_bad/2 6.16 ns 6.15 ns 114101000 BM_to_chars_bad/3 14.5 ns 14.5 ns 48244000 BM_to_chars_bad/4 16.9 ns 16.9 ns 41974000 BM_to_chars_bad/5 12.5 ns 12.5 ns 56080000 BM_to_chars_bad/6 10.9 ns 10.9 ns 64036000 BM_to_chars_bad/7 14.5 ns 14.5 ns 47294000 BM_to_chars_bad/8 6.36 ns 6.35 ns 110430000 BM_to_chars_bad/9 12.4 ns 12.4 ns 56448000 BM_to_chars_bad/10 5.13 ns 5.13 ns 137596000 BM_to_chars_bad/11 9.88 ns 9.88 ns 69015000 BM_to_chars_bad/12 10.8 ns 10.8 ns 63990000 BM_to_chars_bad/13 10.7 ns 10.7 ns 65066000 BM_to_chars_bad/14 9.71 ns 9.71 ns 71775000 BM_to_chars_bad/15 9.18 ns 9.18 ns 75267000 BM_to_chars_bad/16 6.12 ns 6.12 ns 115000000 BM_to_chars_bad/17 10.7 ns 10.7 ns 65504000 BM_to_chars_bad/18 10.6 ns 10.6 ns 65685000 BM_to_chars_bad/19 9.98 ns 9.98 ns 69894000 BM_to_chars_bad/20 9.74 ns 9.74 ns 72098000 BM_to_chars_bad/21 9.25 ns 9.25 ns 75184000 BM_to_chars_bad/22 9.10 ns 9.10 ns 75602000 BM_to_chars_bad/23 9.48 ns 9.48 ns 72824000 BM_to_chars_bad/24 9.27 ns 9.27 ns 75112000 BM_to_chars_bad/25 9.61 ns 9.61 ns 72080000 BM_to_chars_bad/26 9.72 ns 9.72 ns 72178000 BM_to_chars_bad/27 10.0 ns 10.0 ns 69733000 BM_to_chars_bad/28 10.3 ns 10.3 ns 67409000 BM_to_chars_bad/29 9.97 ns 9.97 ns 69193000 BM_to_chars_bad/30 10.1 ns 10.1 ns 69007000 BM_to_chars_bad/31 9.68 ns 9.68 ns 72232000 BM_to_chars_bad/32 8.99 ns 8.99 ns 76825000 BM_to_chars_bad/33 8.82 ns 8.82 ns 79293000 BM_to_chars_bad/34 8.64 ns 8.64 ns 80441000 BM_to_chars_bad/35 8.96 ns 8.96 ns 75320000 BM_to_chars_bad/36 8.87 ns 8.87 ns 77293000 ``` After ``` -------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------- BM_to_chars_good/2 14.7 ns 14.7 ns 47583000 BM_to_chars_good/3 101 ns 101 ns 6901000 BM_to_chars_good/4 68.4 ns 68.4 ns 10088000 BM_to_chars_good/5 58.2 ns 58.2 ns 12007000 BM_to_chars_good/6 51.1 ns 51.1 ns 13687000 BM_to_chars_good/7 45.6 ns 45.6 ns 15323000 BM_to_chars_good/8 14.6 ns 14.6 ns 47795000 BM_to_chars_good/9 40.7 ns 40.7 ns 17371000 BM_to_chars_good/10 7.48 ns 7.48 ns 90931000 BM_to_chars_good/11 37.6 ns 37.6 ns 18542000 BM_to_chars_good/12 35.2 ns 35.2 ns 19922000 BM_to_chars_good/13 34.9 ns 34.9 ns 20105000 BM_to_chars_good/14 33.5 ns 33.5 ns 20863000 BM_to_chars_good/15 31.9 ns 31.9 ns 22014000 BM_to_chars_good/16 11.7 ns 11.7 ns 60012000 BM_to_chars_good/17 28.9 ns 28.9 ns 24148000 BM_to_chars_good/18 29.0 ns 29.0 ns 24317000 BM_to_chars_good/19 28.7 ns 28.7 ns 24363000 BM_to_chars_good/20 28.1 ns 28.1 ns 24899000 BM_to_chars_good/21 27.5 ns 27.5 ns 25499000 BM_to_chars_good/22 26.9 ns 26.9 ns 25929000 BM_to_chars_good/23 26.2 ns 26.2 ns 26828000 BM_to_chars_good/24 25.1 ns 25.1 ns 27742000 BM_to_chars_good/25 25.3 ns 25.3 ns 27720000 BM_to_chars_good/26 25.2 ns 25.2 ns 27789000 BM_to_chars_good/27 25.3 ns 25.3 ns 27777000 BM_to_chars_good/28 25.3 ns 25.3 ns 27643000 BM_to_chars_good/29 25.3 ns 25.3 ns 27750000 BM_to_chars_good/30 25.4 ns 25.4 ns 27566000 BM_to_chars_good/31 25.4 ns 25.4 ns 27611000 BM_to_chars_good/32 25.8 ns 25.8 ns 27218000 BM_to_chars_good/33 25.7 ns 25.7 ns 27070000 BM_to_chars_good/34 26.1 ns 26.1 ns 26693000 BM_to_chars_good/35 26.4 ns 26.4 ns 26486000 BM_to_chars_good/36 26.3 ns 26.3 ns 26619000 BM_to_chars_bad/2 5.99 ns 5.99 ns 118787000 BM_to_chars_bad/3 14.3 ns 14.3 ns 48567000 BM_to_chars_bad/4 16.0 ns 16.0 ns 43239000 BM_to_chars_bad/5 12.6 ns 12.6 ns 55354000 BM_to_chars_bad/6 10.7 ns 10.7 ns 65491000 BM_to_chars_bad/7 14.4 ns 14.4 ns 48723000 BM_to_chars_bad/8 6.50 ns 6.50 ns 104967000 BM_to_chars_bad/9 12.0 ns 12.0 ns 56552000 BM_to_chars_bad/10 5.16 ns 5.16 ns 136380000 BM_to_chars_bad/11 10.5 ns 10.5 ns 66764000 BM_to_chars_bad/12 10.7 ns 10.7 ns 65534000 BM_to_chars_bad/13 11.0 ns 11.0 ns 63426000 BM_to_chars_bad/14 9.90 ns 9.90 ns 68575000 BM_to_chars_bad/15 9.52 ns 9.52 ns 70932000 BM_to_chars_bad/16 6.14 ns 6.14 ns 111762000 BM_to_chars_bad/17 10.6 ns 10.6 ns 65883000 BM_to_chars_bad/18 10.5 ns 10.5 ns 67606000 BM_to_chars_bad/19 9.96 ns 9.96 ns 68898000 BM_to_chars_bad/20 9.40 ns 9.41 ns 73116000 BM_to_chars_bad/21 9.12 ns 9.12 ns 78647000 BM_to_chars_bad/22 8.95 ns 8.95 ns 80211000 BM_to_chars_bad/23 9.50 ns 9.49 ns 73571000 BM_to_chars_bad/24 9.29 ns 9.29 ns 74690000 BM_to_chars_bad/25 9.65 ns 9.65 ns 72877000 BM_to_chars_bad/26 9.78 ns 9.78 ns 70171000 BM_to_chars_bad/27 10.1 ns 10.1 ns 69543000 BM_to_chars_bad/28 10.4 ns 10.4 ns 67582000 BM_to_chars_bad/29 10.00 ns 10.00 ns 70806000 BM_to_chars_bad/30 9.99 ns 9.99 ns 70340000 BM_to_chars_bad/31 9.56 ns 9.56 ns 74159000 BM_to_chars_bad/32 8.97 ns 8.97 ns 78052000 BM_to_chars_bad/33 8.86 ns 8.86 ns 78586000 BM_to_chars_bad/34 8.81 ns 8.81 ns 78562000 BM_to_chars_bad/35 8.90 ns 8.90 ns 77384000 BM_to_chars_bad/36 9.04 ns 9.04 ns 77263000 ``` Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D127764
2022-06-16[libc++][ranges] Implement `ranges::sort`.Konstantin Varlamov1-0/+2
Differential Revision: https://reviews.llvm.org/D127557
2022-06-13[libc++] Do not yield from __sp_mut::lock()Louis Dionne1-12/+11
Instead of trying to be clever and design our own locking primitive, simply rely on the OS-provided implementation to do the right thing. Indeed, manually yielding to the OS does not provide the necessary information for it to make good prioritization decisions. For example, if a thread with higher priority yields while waiting for a lock held by a thread with lower priority but the system is contended, it is possible for the thread with lower priority to not run until the higher priority thread has yielded 16 times and goes for __libcpp_mutex_lock(). Once that happens, the OS can bump the priority of the thread that currently holds the lock to unblock everyone. So instead, we might as well give the system all the information from the start so it can make appropriate decisions. As a fly-by change, also increase the number of locks in the table. The size increase is modest, but has the potential to half the amount of contention on those locks. rdar://93598606 Differential Revision: https://reviews.llvm.org/D126882
2022-06-10[libc++] Granularize <iterator> includesNikolas Klauser1-0/+1
Reviewed By: ldionne, #libc Spies: libcxx-commits, wenlei Differential Revision: https://reviews.llvm.org/D127445
2022-06-07[libc++] Make the Debug mode a configuration-time only optionLouis Dionne1-1/+1
The debug mode has been broken pretty much ever since it was shipped because it was possible to enable the debug mode in user code without actually enabling it in the dylib, leading to ODR violations that caused various kinds of failures. This commit makes the debug mode a knob that is configured when building the library and which can't be changed afterwards. This is less flexible for users, however it will actually work as intended and it will allow us, in the future, to add various kinds of checks that do not assume the same ABI as the normal library. Furthermore, this will make the debug mode more robust, which means that vendors might be more tempted to support it properly, which hasn't been the case with the current debug mode. This patch shouldn't break any user code, except folks who are building against a library that doesn't have the debug mode enabled and who try to enable the debug mode in their code. Such users will get a compile-time error explaining that this configuration isn't supported anymore. In the future, we should further increase the granularity of the debug mode checks so that we can cherry-pick which checks to enable, like we do for unspecified behavior randomization. Differential Revision: https://reviews.llvm.org/D122941
2022-06-07[libc++] Don't use static constexpr in headers.Mark de Wever1-1/+1
This was noticed in the review of D125704. In that commit only the new table has been adapted. This adapts the existing tables. Note since libc++'s charconv is backported to C++11 it's not possible to use inline constexpr variables. The were introduced in C++17. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D126887
2022-06-02[libc++] Lets to_chars use header implementation.Mark de Wever2-133/+12
This removes the duplicated code from the dylib. Instead the dylib will call the new functions in the header. Since this code is unneeded it's removed from the unstable ABI. Depends on D125704 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D125761
2022-06-02[libc++] Make to_chars base 10 header only.Mark de Wever1-2/+2
The functions to_chars and from_chars should offer 128-bit support. This is the first step to implement 128-bit version of to_chars. Before implementing 128-bit support the current code will be polished. This moves the code from the dylib to the header in prepartion of P2291 "Add Constexpr Modifiers to Functions to_chars and from_chars for Integral Types in <charconv> Header" Note some more cleanups will be done in follow-up commits - Remove the _LIBCPP_AVAILABILITY_TO_CHARS from to_chars. With all code in the header the availablilty macro is no longer needed. This requires enabling the unit tests for additional platforms. - The code in the dylib can switch to using the header implementation. This allows removing the code duplicated in the header and the dylib. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D125704
2022-05-28[libc++] Minor emscripten changes from downstreamSam Clegg1-0/+2
Differential Revision: https://reviews.llvm.org/D126583
2022-05-26[libc++][NFC] Fix whitespaceLouis Dionne1-1/+0
2022-05-25[libc++] Remove conditional includeLouis Dionne1-1/+1
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-05-19[runtimes] Fix the build of merged ABI/unwinder librariesLouis Dionne1-3/+3
Also, add a CI job that tests this configuration. The exact configuration is that we build a shared libc++ and merge objects for the ABI library and the unwinder library into it. Differential Revision: https://reviews.llvm.org/D125903
2022-05-18[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on WindowsMartin Storsjö1-1/+3
(In the case of libunwind, the cmake option is called LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as LIBCXX_HERMETIC_STATIC_LIBRARY and LIBCXXABI_HERMETIC_STATIC_LIBRARY.) Previously, the same issue was dealt with by setting a project wide define (_LIBUNWIND_HIDE_SYMBOLS, _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static library. If building both static and shared at the same time, this wasn't set, and the static library would contain dllexport directives. The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake options only apply the defines to the static library in the build, even if building both static and shared at the same time. (This could only be done use after the object libraries were enabled, as a shared libcxx needs libcxxabi object files built with dllexports included.) This allows removing inelegant code for deciding how to build the libcxxabi static library and a TODO comment that suggested that users should need to start setting an option, which they shouldn't need to. Finally, this gets rid of two XFAILs in tests. Differential Revision: https://reviews.llvm.org/D125715
2022-05-17[libc++] Introduce LIBCXX_LIBRARY_VERSIONLouis Dionne1-1/+1
This allows controlling the current_version linker property on Apple platforms. Differential Revision: https://reviews.llvm.org/D125686
2022-05-16[libc++] Remove the legacy LIBCXX_LIBCPPABI_VERSION optionLouis Dionne1-1/+1
I think this notion of libc++abi's version was relevant a long time ago on Apple platforms when we were using a Xcode project to build the library. As part of moving Apple's build to CMake, D59489 made it possible to specify the "ABI version" of libc++abi in use. However, it's not possible to build libc++abi with that old ABI anymore and we don't need the ability to link against that version from libc++ anymore. Hence, we can clean this up and stop falsely pretending that libc++abi has more than one ABI version. Differential Revision: https://reviews.llvm.org/D125687
2022-05-16[runtimes] Introduce object librariesLouis Dionne1-28/+5
This is a variant of D116689 rebased on top of the new (proposed) ABI refactoring in D120727. It should conserve the basic properties of the original patch by @phosek, except it also allows cleaning up the merging of libc++abi into libc++ from the libc++ side. Differential Revision: https://reviews.llvm.org/D125393
2022-05-13[libc++] Overhaul how we select the ABI libraryLouis Dionne1-30/+8
This patch overhauls how we pick up the ABI library. Instead of setting ad-hoc flags, it creates interface targets that can be linked against by the rest of the build, which is easier to follow and extend to support new ABI libraries. This is intended to be a NFC change, however there are some additional simplifications and improvements we can make in the future that would require a slight behavior change. Differential Revision: https://reviews.llvm.org/D120727
2022-05-05Fix "the the" typo in documentation and user facing stringsBrian Tracy1-1/+1
There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users. Reviewed By: #libc, Mordante, martong, ldionne Differential Revision: https://reviews.llvm.org/D124708
2022-04-25[libc++] Avoid lifetime UB in __thread_local_data()Vitaly Buka1-2/+7
Detected on many lld tests with -fsanitize-memory-use-after-dtor. Also https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-fast after D122869 will report a lot of them. Threads may outlive static variables. Even if ~__thread_specific_ptr() does nothing, lifetime of members ends with ~ and accessing the value is UB https://eel.is/c++draft/basic.life#1 ``` ==9214==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x557e1cec4539 in __libcpp_tls_set ../include/c++/v1/__threading_support:428:12 #1 0x557e1cec4539 in set_pointer ../include/c++/v1/thread:196:5 #2 0x557e1cec4539 in void* std::__msan::__thread_proxy< std::__msan::tuple<...>, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()> >(void*) ../include/c++/v1/thread:285:27 Memory was marked as uninitialized #0 0x557e10a0759d in __sanitizer_dtor_callback compiler-rt/lib/msan/msan_interceptors.cpp:940:5 #1 0x557e1d8c478d in std::__msan::__thread_specific_ptr<std::__msan::__thread_struct>::~__thread_specific_ptr() libcxx/include/thread:188:1 #2 0x557e10a07dc0 in MSanCxaAtExitWrapper(void*) compiler-rt/lib/msan/msan_interceptors.cpp:1151:3 ``` The test needs D123979 or -fsanitize-memory-param-retval enabled by default. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D122864
2022-04-12[libc++] Define legacy symbols for inline functions at a finer-grained levelLouis Dionne2-4/+13
When we build the library with the stable ABI, we need to include some functions in the dylib that were made inline in later versions of the library (to avoid breaking code that might be relying on those symbols). However, those methods were made non-inline whenever we'd be building the library, which means that all translation units would end up using the old out-of-line definition of these methods, as opposed to the new inlined version. This patch makes it so that only the translation units that actually define the out-of-line methods use the old definition, opening up potential optimization opportunities in other translation units. This should solve some of the issues encountered in D65667. Differential Revision: https://reviews.llvm.org/D123519
2022-04-08[libc++] Rename PS() macro to avoid clashing with Xtensa register nameGustavo Henrique Nihei2-24/+24
This patch addresses a clash with the PS register from Xtensa defined in the <specreg.h> header file, which is commonly included in OS implementation. Issue identified while building libc++ port for Apache NuttX, targeting Xtensa-based chips (e.g. Espressif's ESP32). Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com> Differential Revision: https://reviews.llvm.org/D122479
2022-03-28[libcxx] random_device, specify optimal entropy properties for all OS's ↵Brad Smith1-1/+1
using arc4random() Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D122522
2022-03-24[libc++] Audit all uses of _LIBCPP_ASSERT and _LIBCPP_DEBUG_ASSERTLouis Dionne1-1/+1
I audited all uses of _LIBCPP_ASSERT to make sure that we only used it for "basic assertions", i.e. assertions with constant-time conditions. I also audited all uses of _LIBCPP_DEBUG_ASSERT to make sure we used it only for debug-mode assertions, and in one case had to change for _LIBCPP_ASSERT instead. As a fly-by, I also changed a couple of tests against nullptr or 0 to be more explicit. After this patch, all uses of _LIBCPP_ASSERT should be with constant-time conditions, and all uses of _LIBCPP_DEBUG_ASSERT should be with conditions that we only want to check when the debug mode is enabled. Differential Revision: https://reviews.llvm.org/D122395
2022-03-23[libc++] Add a lightweight overridable assertion handlerLouis Dionne3-21/+60
This patch adds a lightweight assertion handler mechanism that can be overriden at link-time in a fashion similar to `operator new`. This is a third take on https://llvm.org/D121123 (which allowed customizing the assertion handler at compile-time), and https://llvm.org/D119969 (which allowed customizing the assertion handler at runtime only). This approach is, I think, the best of all three explored approaches. Indeed, replacing the assertion handler in user code is ergonomic, yet we retain the ability to provide a custom assertion handler when deploying to older platforms that don't have a default handler in the dylib. As-is, this patch provides a pretty good amount of backwards compatibility with the previous debug mode: - Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions in their code will still get basic assertions out of the box, but those assertions will be using the new assertion handler support. - Code that was previously compiled with references to __libcpp_debug_function and friends will work out-of-the-box, no changes required. This is because we provide the same symbols in the dylib as we used to. - Code that used to set a custom __libcpp_debug_function will stop compiling, because we don't provide that declaration anymore. Users will have to migrate to the new way of setting a custom assertion handler, which is extremely easy. I suspect that pool of users is very limited, so breaking them at compile-time is probably acceptable. The main downside of this approach is that code being compiled with assertions enabled but deploying to an older platform where the assertion handler didn't exist yet will fail to compile. However users can easily fix the problem by providing a custom assertion handler and defining the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to let the library know about the custom handler. In a way, this is actually a feature because it avoids a load-time error that one would otherwise get when trying to run the code on the older target. Differential Revision: https://reviews.llvm.org/D121478
2022-03-17[libc++] Add warning pragma macros in the test suiteNikolas Klauser1-8/+7
Reviewed By: ldionne, #libc, EricWF Spies: EricWF, libcxx-commits Differential Revision: https://reviews.llvm.org/D121552
2022-02-28[libc++] Fix double file closing in `std::filesystem::remove_all()`.Konstantin Varlamov1-1/+3
According to Linux documentation (see e.g. https://linux.die.net/man/3/closedir): > A successful call to `closedir()` also closes the underlying file > descriptor associated with `dirp`. Thus, calling `close()` after a successful call to `closedir()` is at best redundant. Worse, should a different thread open a file in-between the calls to `closedir()` and `close()` and get the same file descriptor, the call to `close()` might actually close a different file than was intended. rdar://89251874 Differential Revision: https://reviews.llvm.org/D120453
2022-02-25[libcxx] Fix the error checking for wctob_l, fixing locale narrow function ↵Martin Storsjö1-2/+2
on Windows According to POSIX.1 (and Glibc docs, and Microsoft docs), the wctob function returns EOF on error, not WEOF. (And wctob_l should consequently do the same.) The previous misconception about what this function returns on errors seems to stem from incorrect documentation in macOS, stemming from BSD docs with the same issue. The corresponding documentation bug in FreeBSD was fixed in 2012 in https://github.com/freebsd/freebsd-src/commit/945aab90991bdaeabeb6ef25112975a96c01dd4e, but it hasn't been fixed for macOS yet. The issue seems to only be a documentation issue; the implementation on macOS actually does use EOF, not WEOF: https://opensource.apple.com/source/Libc/Libc-1439.40.11/locale/FreeBSD/wctob.c.auto.html On most Unices, EOF and WEOF are the same value, but on Windows, EOF is -1, while WEOF is (unsigned short)0xFFFF. By fixing this, two tests start passing on Windows. Differential Revision: https://reviews.llvm.org/D120088
2022-02-24[libc++] Make sure calls to std::move are always qualifiedCorentin Jabot1-9/+9
This fixes instances of the newly added `-Wunqualified-std-cast-call`. (Commit 7853371146 removed unqualified `move` from the tests, but these unqualified `move`s remained undetected in the actual headers.) Differential Revision: https://reviews.llvm.org/D120509
2022-02-16[libc++] Move everything related solely to _LIBCPP_ASSERT to its own fileLouis Dionne18-23/+55
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'Dwyer56-218/+244
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-15[libc++] Rename *SAFE_STATIC to *CONSTINIT, and normalize its uses.Arthur O'Dwyer8-18/+14
In src/, most files can use `constinit` directly because they're always compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp", can't, because they're `#include`d directly from test cases in libcxxabi/test/ and therefore must (currently) compile as C++03. We might consider refactoring those offending tests, or at least marking them `UNSUPPORTED: c++03`. Differential Revision: https://reviews.llvm.org/D119264
2022-02-15[libc++][AIX] Remove "pragma priority" from locale.cppXing Xue1-5/+0
Summary: The pragma priority guarded for AIX in locale.cpp is no longer useful and is ignored by the current AIX build compilers. This patch removes it from the source. Reviewed by: ldionne, hubert.reinterpretcast, libc++ Differential Revision: https://reviews.llvm.org/D119765
2022-02-15[libc++] Guard warning pragmasNikolas Klauser5-36/+18
This makes the GCC output even cleaner! Reviewed By: ldionne, #libc Spies: mstorsjo, Quuxplusone, Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D119295
2022-02-14[libcxx] Fix setup of MSVC specific intrinsics in Ryu codeMartin Storsjö2-5/+7
This fixes warnings about implicitly declared `_umul128` and `__shiftright128` when building for x86_64 with clang-cl. Use `_MSC_VER` instead of `_LIBCPP_COMPILER_MSVC` for enabling MSVC specific code; `_MSC_VER` is defined both in clang-cl and MSVC, while `_LIBCPP_COMPILER_MSVC` only is defined if building with the actual MSVC compiler. Include `ryu.h` at the head of `d2s_intrinsics.h`, as it uses the `_LIBCPP_64_BIT` define, which is defined in `ryu.h`. Now the Ryu files build without warnings with clang-cl for i386, x86_64, arm and aarch64. Differential Revision: https://reviews.llvm.org/D119647
2022-02-14[libc++] Implement P0627R6 (Function to mark unreachable code)Nikolas Klauser4-13/+16
Reviewed By: ldionne, Quuxplusone, #libc Spies: arichardson, mstorsjo, libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D119152
generated by cgit v1.1 at 2025-10-03 07:16:32 +0000