Changes in ios

f69585235ec85d54e0f3fc41b2d5700430907f99 - [libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710)

Wed, 08 Jan 2025 16:12:59 +0000

[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710)This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. List of files: /llvm-project/libcxx/include/ios

b9a2658a3e8bd13b0f9e7a8a440832a95b377216 - [libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)

Sat, 21 Dec 2024 12:01:48 +0000

[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)This patch implements the forwarding to frozen C++03 headers asdiscussed inhttps://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In theRFC, we initially proposed selecting the right headers from the Clangdriver, however consensus seemed to steer towards handling this in thelibrary itself. This patch implements that direction.At a high level, the changes basically amount to making each publicheader look like this:```// inside #ifdef _LIBCPP_CXX03_LANG# include <__cxx03/vector>#else // normal content#endif```In most cases, public headers are simple umbrella headers so there isn'tmuch code in the #else branch. In other cases, the #else branch containsthe actual implementation of the header. List of files: /llvm-project/libcxx/include/ios

c166a9c713ec86b86f1f178a5133bc128fd0a610 - [libc++] Add #if 0 block to all the top-level headers (#119234)

Tue, 10 Dec 2024 15:02:12 +0000

[libc++] Add #if 0 block to all the top-level headers (#119234)Including The frozen C++03 headers results in a lot of formattingchanges in the main headers, so this splits these changes into aseparate commit instead.This is part ofhttps://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. List of files: /llvm-project/libcxx/include/ios

c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c - [libc++] Refactor the configuration macros to being always defined (#112094)

Wed, 06 Nov 2024 09:39:19 +0000

[libc++] Refactor the configuration macros to being always defined (#112094)This is a follow-up to #89178. This updates the `<__config_site>`macros. List of files: /llvm-project/libcxx/include/ios

ba87515fea90b5d55836a8e3be63a7e683ce299d - [libc++][RFC] Always define internal feature test macros (#89178)

Sat, 12 Oct 2024 07:49:52 +0000

[libc++][RFC] Always define internal feature test macros (#89178)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>`. List of files: /llvm-project/libcxx/include/ios

f3a4def436618c24e2eb9faa812994beb2cd7744 - [libcxx][ios] initialize __fill_val_ in _FillHelper (#110279)

Mon, 30 Sep 2024 23:24:32 +0000

[libcxx][ios] initialize __fill_val_ in _FillHelper (#110279)This is a small fix to https://github.com/llvm/llvm-project/pull/89305. In the `__init` function of `_FillHelper`, `__fill_val_` was left uninitialized. This worked for the implementation in the PR because we always checked `__set_` before trying to read it, and would initialize if it was unset. However it turns out in earlier versions of the header (at least on AIX which followed this path), we do a read of `__fill_val_` even if `__set_` was false before initializing, to check if it matched the sentinel value, so this causes undesired behaviour and UB. List of files: /llvm-project/libcxx/include/ios

748023dc3210533df2c1c6efc8af1b5954493701 - [libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)

Wed, 11 Sep 2024 06:59:46 +0000

[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)`[[__noreturn__]]` is now always available, so we can simply use the attribute directly instead of through a macro. List of files: /llvm-project/libcxx/include/ios

4dee6411e0d993fd17099bd7564276474412383e - [libc++] Implements LWG3130. (#101889)

Tue, 06 Aug 2024 17:47:56 +0000

[libc++] Implements LWG3130. (#101889)This adds addressof at the required places in [input.output]. Some of the new tests failed since string used operator& internally. These have been fixed too. Note the new fstream tests perform output to a basic_string instead of a double. Using a double requires num_get specialization num_get> This facet is not present in the locale database so the conversion would fail due to a missing locale facet. Using basic_string avoids using the locale. As a drive-by fixes several bugs in the ofstream.cons tests. These tested ifstream instead of ofstream with an open mode. Implements: - LWG3130 [input.output] needs many addressof Closes #100246. List of files: /llvm-project/libcxx/include/ios

194f98c2210bf40d0490613fddbf83e04c18ad9b - [libc++] basic_ios cannot store fill character WCHAR_MAX (#89305)

Wed, 17 Jul 2024 18:47:13 +0000

[libc++] basic_ios cannot store fill character WCHAR_MAX (#89305)`libcxx std::basic_ios` uses `WEOF` to indicate the `fill` value is uninitialized. On some platforms (e.g AIX and zOS in 64-bit mode) `wchar_t` is 4 bytes `unsigned` and `wint_t` is also 4 bytes which means `WEOF` cannot be distinguished from `WCHAR_MAX` by `std::char_traits::eq_int_type()`, meaning this valid character value cannot be stored on affected platforms (as the implementation triggers reinitialization to `widen(’ ’)`). This patch introduces a new helper class `_FillHelper` uses a boolean variable to indicate whether the fill character has been initialized, which is used by default in libcxx ABI version 2. The patch does not affect ABI version 1 except for targets AIX in 32- and 64-bit and z/OS in 64-bit (so that the layout of the implementation is compatible with the current IBM system provided libc++) This is a continuation of Phabricator patch [D124555](https://reviews.llvm.org/D124555). This patch uses a modified version of the [approach](https://reviews.llvm.org/D124555#3566746) suggested by @ldionne . --------- Co-authored-by: Louis Dionne Co-authored-by: David Tenty List of files: /llvm-project/libcxx/include/ios

ef51e617c43ef4248973f07e0a711f69d85c948c - [libc++] Handle _LIBCPP_HAS_NO_{THREADS,LOCALIZATION} consistently with other carve-outs (#98319)

Mon, 15 Jul 2024 14:11:23 +0000

[libc++] Handle _LIBCPP_HAS_NO_{THREADS,LOCALIZATION} consistently with other carve-outs (#98319)Previously, we would issue an #error when using a header that requires threading support or localization support in a configuration where that is disabled. This is unlike what we do for all the other carve outs like no-filesystem, no-wide-characters or no-random-device. Instead of issuing an #error, we normally just remove the problematic parts of the header. This patch makes the handling of no-localization and no-threads consistent with the other carve-outs. I dislike the fact that users won't get an explicit error message when trying to use e.g. ios in a build that doesn't support localization, but I think it is better to handle things consistently. Note that besides the consistency argument, the #error approach doesn't really work anyways since it would break down if we moved towards assuming the C locale only in the no-localization mode. List of files: /llvm-project/libcxx/include/ios

6b4b29f85900995b2a3b817548be4a534d46763b - [libc++][NFC] Remove unnecessary parens in static_asserts (#95605)

Tue, 18 Jun 2024 08:45:30 +0000

[libc++][NFC] Remove unnecessary parens in static_asserts (#95605)These were required a long time ago due to `static_assert` not actually being available in C++03. Now `static_assert` is simply mapped to `_Static_assert` in C++03, making the additional parens unnecessary. List of files: /llvm-project/libcxx/include/ios

e09761944cea4aeafadd055b9510ef9f0e9a7338 - [libc++] Improves UB handling in ios_base destructor. (#76525)

Tue, 12 Mar 2024 17:04:14 +0000

[libc++] Improves UB handling in ios_base destructor. (#76525)Destroying an ios_base object before it is properly initialized is undefined behavior. Unlike typical C++ classes the initialization is not done in the constructor, but in a dedicated init function. Due to virtual inheritance of the basic_ios object in ostream and friends this undefined behaviour can be triggered when inheriting from classes that can throw in their constructor and inheriting from ostream. Use the __loc_ member of ios_base as sentinel to detect whether the object has or has not been initialized. Addresses https://github.com/llvm/llvm-project/issues/57964 List of files: /llvm-project/libcxx/include/ios

37dca605c9bd41732da010ee97ed15ad9585a37d - [libc++] Clean up includes of <__assert> (#80091)

Thu, 29 Feb 2024 15:12:22 +0000

[libc++] Clean up includes of <__assert> (#80091)Originally, we used __libcpp_verbose_abort to handle assertion failures. That function was declared from all public headers. Since we don't use that mechanism anymore, we don't need to declare __libcpp_verbose_abort from all public headers, and we can clean up a lot of unnecessary includes. This patch also moves the definition of the various assertion categories to the <__assert> header, since we now rely on regular IWYU for these assertion macros. rdar://105510916 List of files: /llvm-project/libcxx/include/ios

7b4622514d232ce5f7110dd8b20d90e81127c467 - [libc++] Fix missing and incorrect push/pop macros (#79204)

Thu, 25 Jan 2024 20:48:46 +0000

[libc++] Fix missing and incorrect push/pop macros (#79204)We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like `move`, we'd push `move(int, int)` in the pragma, which is not a valid macro name. As a result, we would not actually push macros like `move` -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like `move` in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 List of files: /llvm-project/libcxx/include/ios

9783f28cbb155e4a8d49c12e1c60ce14dcfaf0c7 - [libc++] Format the code base (#74334)

Mon, 18 Dec 2023 19:01:33 +0000

[libc++] Format the code base (#74334)This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all List of files: /llvm-project/libcxx/include/ios

77a00c0d546cd4aa8311b5b9031ae9ea8cdb050c - [libc++] Replace uses of _VSTD:: by std:: (#74331)

Tue, 05 Dec 2023 16:19:15 +0000

[libc++] Replace uses of _VSTD:: by std:: (#74331)As part of the upcoming clang-formatting of libc++, this patch performs the long desired removal of the _VSTD macro. See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all for the clang-format proposal. List of files: /llvm-project/libcxx/include/ios

4c198542226223f6a5c5511a1f89b37d15ee10b9 - [libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

Mon, 04 Dec 2023 15:25:14 +0000

[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)In preparation for running clang-format on the whole code base, we are also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in favor of the newer _LIBCPP_HIDE_FROM_ABI. We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid creating needless breakage in case some older patches are checked-in with mentions of the old macro. After we branch for LLVM 18, we can do another pass to clean up remaining uses of the macro that might have gotten introduced by mistake (if any) and remove the macro itself at the same time. This is just a minor convenience to smooth out the transition as much as possible. See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all for the clang-format proposal. List of files: /llvm-project/libcxx/include/ios

a3f17ba3febbd546f2342ffc780ac93b694fdc8d - [libc++] Implement P2467R1: Support exclusive mode for fstreams

Mon, 18 Sep 2023 20:32:02 +0000

[libc++] Implement P2467R1: Support exclusive mode for fstreamsThis patch brings std::ios_base::noreplace from P2467R1 to libc++.This requires compiling the shared library in C++23 mode since otherwisefstream::open(...) doesn't know about the new flag.Differential Revision: https://reviews.llvm.org/D137640Co-authored-by: Louis Dionne List of files: /llvm-project/libcxx/include/ios

c01794e7ae8e37052e2268e7447d51665e073356 - [libc++] Move once_flag outside of

Mon, 17 Jul 2023 16:42:00 +0000

[libc++] Move once_flag outside of This allows including once_flag directly from <__locale> instead ofdepending on all of , which requires threading. In turn, thismakes it easier to support locales on platforms without threading.Drive-by change: clang-format once_flag.h and use _LIBCPP_HIDE_FROM_ABIDifferential Revision: https://reviews.llvm.org/D155487 List of files: /llvm-project/libcxx/include/ios

f1ea0b11ca03d0f8b5785b7ec92d2eb673eeb4b9 - [libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

Wed, 14 Jun 2023 17:17:50 +0000

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABIThese macros are always defined identically, so we can simplify the code a bit by merging them.Reviewed By: ldionne, #libcSpies: libcxx-commits, krytarowski, smeenaiDifferential Revision: https://reviews.llvm.org/D152652 List of files: /llvm-project/libcxx/include/ios