summaryrefslogtreecommitdiff
path: root/libcxx/include/__system_error/system_error.h
AgeCommit message (Collapse)Author
2025-05-28Revert "[libc++] Introduce ABI sensitive areas to avoid requiring ↵James Y Knight
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756) This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521. Unfortunately, this use of hidden visibility attributes causes user-defined specializations of standard-library types to also be marked hidden by default, which is incorrect. See discussion thread on #131156. ...and also reverts the follow-up commits: Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)" This reverts commit 3e4c9dc299c35155934688184319d391b298fff7. Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)" This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5. Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)" This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
2025-05-18[libc++] Introduce ABI sensitive areas to avoid requiring ↵Nikolas Klauser
_LIBCPP_HIDE_FROM_ABI everywhere (#131156) This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`, which allow us to have implicit annotations for most functions, and just where it's not "hide_from_abi everything" we add explicit annotations. This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most functions in libc++.
2025-01-08[libcxx] Handle windows system error code mapping in std::error_code. (#93101)James Y Knight
The `std::error_code`/`std::error_category` functionality is designed to support multiple error domains. On Unix, both system calls and libc functions return the same error codes, and thus, libc++ today treats `generic_category()` and `system_category()` as being equivalent. However, on Windows, libc functions return `errno.h` error codes in the `errno` global, but system calls return the very different `winerror.h` error codes via `GetLastError()`. As such, there is a need to map the winerror.h error codes into generic errno codes. In libc++, however, the system_error facility does not implement this mapping; instead the mapping is hidden inside libc++, used directly by the std::filesystem implementation. That has a few problems: 1. For std::filesystem APIs, the concrete windows error number is lost, before users can see it. The intent of the distinction between std::error_code and std::error_condition is that the error_code return has the original (potentially more detailed) error code. 2. User-written code which calls Windows system APIs requires this same mapping, so it also can also return error_code objects that other (cross-platform) code can understand. After this commit, an `error_code` with `generic_category()` is used to report an error from `errno`, and, on Windows only, an `error_code` with `system_category()` is used to report an error from `GetLastError()`. On Unix, system_category remains identity-mapped to generic_category, but is never used by libc++ itself. The windows error code mapping is moved into system_error, so that conversion of an `error_code` to `error_condition` correctly translates the `system_category()` code into a `generic_category()` code, when appropriate. This allows code like: `error_code(GetLastError(), system_category()) == errc::invalid_argument` to work as expected -- as it does with MSVC STL. (Continued from old phabricator review [D151493](https://reviews.llvm.org/D151493))
2024-11-16[libc++] Avoid including <string> in <mutex> (#116254)Nikolas Klauser
2024-10-12[libc++][RFC] Always define internal feature test macros (#89178)Nikolas Klauser
Currently, the library-internal feature test macros are only defined if the feature is not available, and always have the prefix `_LIBCPP_HAS_NO_`. This patch changes that, so that they are always defined and have the prefix `_LIBCPP_HAS_` instead. This changes the canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means that using an undefined macro (e.g. due to a missing include) is diagnosed now. While this is rather unlikely currently, a similar change in `<__configuration/availability.h>` caught a few bugs. This also improves readability, since it removes the double-negation of `#ifndef _LIBCPP_HAS_NO_FEATURE`. The current patch only touches the macros defined in `<__config>`. If people are happy with this approach, I'll make a follow-up PR to also change the macros defined in `<__config_site>`.
2024-09-11[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] ↵Nikolas Klauser
(#80455) `[[__noreturn__]]` is now always available, so we can simply use the attribute directly instead of through a macro.
2023-08-29[libc++] Adds __throw_system_error overload.Mark de Wever
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-11[libc++] Optimize internal function in <system_error>Edoardo Sanguineti
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-06-15[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI ↵Nikolas Klauser
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-04-16[libc++] Add hide_from_abi check for classesNikolas Klauser
We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library. Reviewed By: ldionne, Mordante, #libc Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai Differential Revision: https://reviews.llvm.org/D142332
2023-04-12[NFC][libc++] Use _LIBCPP_HIDE_FROM_ABI.Mark de Wever
This updates the new __system_error directory. Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D148028
2023-04-11[libc++] Formats the sytem_error headers.Mark de Wever
Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D147886
2023-04-09[libc++] Granularize system_error.Mark de Wever
Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D147853