| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
Fix "the the" typo in documentation and user facing strings 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 | 4 年前 | |
[libc++] Implement P1004R2 (constexpr std::vector) 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 (cherry picked from commit 98d3d5b5da66e3cf7807c23a0294280bb796466b) | 3 年前 | |
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file 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 | 4 年前 | |
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file 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 | 4 年前 | |
[libc++] Simplify how we define the linker script for libc++ 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 (cherry picked from commit b7fb8563974d83f9eb8191fdfbebfd04147a2cbd) | 3 年前 | |
[libc++][ranges] Implement ranges::sort. Differential Revision: https://reviews.llvm.org/D127557 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Split a few utilities out of __threading_support This change is the basis for a further refactoring where I'm going to split up the various implementations we have in __threading_support to make that code easier to understand. Note that I had to make __convert_to_timespec a template to break circular dependencies. Concretely, we never seem to use it with anything other than ::timespec, but I am wary of hardcoding that assumption as part of this change, since I suspect there's a reason for going through these hoops in the first place. Differential Revision: https://reviews.llvm.org/D116944 | 4 年前 | |
[libc++] Remove conditional include | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Improve charconv base10 algorithm. 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 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
Ensure newlines at the end of files (NFC) | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
Ensure newlines at the end of files (NFC) | 4 年前 | |
[libc++] Add a lightweight overridable assertion handler 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Implement P0618R0 (Deprecating <codecvt>) Reviewed By: ldionne, #libc Spies: cfe-commits, llvm-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D127313 | 3 年前 | |
[libc++] Do not yield from __sp_mut::lock() 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 | 3 年前 | |
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libcxx] random_device, specify optimal entropy properties for all OS's using arc4random() Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D122522 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++][NFC] Whitespace refactoring of string.cpp for consistency and legibility | 4 年前 | |
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file 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 | 4 年前 | |
[libc++] Define legacy symbols for inline functions at a finer-grained level 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 | 4 年前 | |
[libc++] Avoid lifetime UB in __thread_local_data() 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. 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 | 4 年前 | |
[libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abort 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 (cherry picked from commit 507125af3d0b953cb56bce2e5b8000249fe1ef53) | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 |