| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Revert "Protect users from relying on detail headers" & related changes This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9, which were related to the original commit). As landed, 5aaefa51 had unintended consequences on some downstream bots and didn't have proper coverage upstream due to a few subtle things. Implementing this is something we should do in libc++, however we'll first need to address a few issues listed in https://reviews.llvm.org/D106124#3349710. Differential Revision: https://reviews.llvm.org/D120683 | 4 年前 | |
[libc++] Revert "Protect users from relying on detail headers" & related changes This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9, which were related to the original commit). As landed, 5aaefa51 had unintended consequences on some downstream bots and didn't have proper coverage upstream due to a few subtle things. Implementing this is something we should do in libc++, however we'll first need to address a few issues listed in https://reviews.llvm.org/D106124#3349710. Differential Revision: https://reviews.llvm.org/D120683 | 4 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++][Modules] Make module exports consistent with header includes Some modules export modules that they don't import (i.e. that their header doesn't directly include). That sometimes works when the exported submodule is in the same module, but when the std mega module is broken up (D144322), some of the exports stop working. Make the exports and includes consistent, either by adding includes for the exports, or by removing exports for missing includes. The concepts.equality_comparable export in std.iterator.__iterator.concepts isn't doing anything because 1) it's resolved as std.iterator.__iterator.concepts.equality_comparable and 2) there's a __concepts submodule in between std.concepts and equality_comparable. Fix it to be std.concepts.__concepts.equality_comparable. <span> is listed in both std.span and std.experimental.span. Delete the latter module. There is no __errc module or header, so remove that export from std.system_error. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D153211 | 3 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM 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 | 3 年前 | |
[libc++] Rename availability macros for <filesystem> This makes it clearer that the availability macro only pertains to <filesystem>, and not to whether the platform has support for a file system. Differential Revision: https://reviews.llvm.org/D152172 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 |