History log of /llvm-project/libcxx/include/sstream (Results 1 – 25 of 84)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7
# b9a2658a 21-Dec-2024 Nikolas Klauser <nikolasklauser@berlin.de>

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

This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-

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

This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.

At a high level, the changes basically amount to making each public
header look like this:

```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```

In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.

show more ...


Revision tags: llvmorg-19.1.6
# c166a9c7 10-Dec-2024 Nikolas Klauser <nikolasklauser@berlin.de>

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

Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
sep

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

Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
separate commit instead.

This is part of
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.

show more ...


Revision tags: llvmorg-19.1.5, llvmorg-19.1.4
# c6f3b7bc 06-Nov-2024 Nikolas Klauser <nikolasklauser@berlin.de>

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

This is a follow-up to #89178. This updates the `<__config_site>`
macros.


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2
# ba87515f 12-Oct-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[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
`

[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>`.

show more ...


Revision tags: llvmorg-19.1.1, llvmorg-19.1.0
# 09e3a360 16-Sep-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++][modules] Fix missing and incorrect includes (#108850)

This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to

[libc++][modules] Fix missing and incorrect includes (#108850)

This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.

show more ...


# 87d56c59 16-Sep-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++][modules] Guard carved-out headers more consistently (#108637)

Several headers that should not be provided when localization or threads
are disabled were not guarded. That works until one t

[libc++][modules] Guard carved-out headers more consistently (#108637)

Several headers that should not be provided when localization or threads
are disabled were not guarded. That works until one tries to build with
modules and these headers get pulled in.

Note that this could be cleaned up further into something more
systematic, but this patch solves the immediate problems I ran into with
the monolithic modulemap and doesn't create any new inconsistency that
wasn't already there.

show more ...


Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3
# 4dee6411 06-Aug-2024 Mark de Wever <koraq@xs4all.nl>

[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.

[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<CharT, istreambuf_iterator<CharT,
char_traits_operator_hijacker<CharT>>

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.

show more ...


Revision tags: llvmorg-19.1.0-rc2
# d5a6ec1d 01-Aug-2024 Mark de Wever <koraq@xs4all.nl>

[libc++][stringbuf] Test and document LWG2995. (#100879)

As mentioned in the LWG issue libc++ has already implemented the
optimization. This adds tests and documents the implementation defined
beh

[libc++][stringbuf] Test and document LWG2995. (#100879)

As mentioned in the LWG issue libc++ has already implemented the
optimization. This adds tests and documents the implementation defined
behaviour.

Drive-by fixes an initialization.

show more ...


Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7
# 04f01a2b 29-May-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++] Make the __availability header a sub-header of __config (#93083)

In essence, this header has always been related to configuration of
the library but we didn't want to put it inside <__conf

[libc++] Make the __availability header a sub-header of __config (#93083)

In essence, this header has always been related to configuration of
the library but we didn't want to put it inside <__config> due to
complexity reasons. Now that we have sub-headers in <__config>, we
can move <__availability> to it and stop including it everywhere since
we already obtain the required macros via <__config>.

show more ...


Revision tags: llvmorg-18.1.6
# 17f00620 02-May-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++] Granularize <ostream> (#85537)

This also includes `<__ostream/basic_ostream.h>` in `<sstream>` now,
reducing the include time of `<complex>` from 819ms to 603ms.


Revision tags: llvmorg-18.1.5
# 95e668f8 20-Apr-2024 Mark de Wever <koraq@xs4all.nl>

[libc++] Removes a Clang 16 Windows workaround. (#88560)


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1
# 80f9458c 05-Mar-2024 Hristo Hristov <hghristov.rmm@gmail.com>

[libc++][sstream] P2495R3: Interfacing `stringstream`s with `string_view` (#80552)

Implements P2495R3 <https://wg21.link/P2495R3>
- https://eel.is/c++draft/version.syn#headerref:%3csstream%3e
- ht

[libc++][sstream] P2495R3: Interfacing `stringstream`s with `string_view` (#80552)

Implements P2495R3 <https://wg21.link/P2495R3>
- https://eel.is/c++draft/version.syn#headerref:%3csstream%3e
- https://eel.is/c++draft/stringbuf
- https://eel.is/c++draft/stringbuf.general
- https://eel.is/c++draft/stringbuf.cons
- https://eel.is/c++draft/stringbuf.members
- https://eel.is/c++draft/istringstream
- https://eel.is/c++draft/istringstream.general
- https://eel.is/c++draft/istringstream.cons
- https://eel.is/c++draft/istringstream.members
- https://eel.is/c++draft/ostringstream
- https://eel.is/c++draft/ostringstream.general
- https://eel.is/c++draft/ostringstream.cons
- https://eel.is/c++draft/ostringstream.members
- https://eel.is/c++draft/stringstream
- https://eel.is/c++draft/stringstream.general
- https://eel.is/c++draft/stringstream.cons
- https://eel.is/c++draft/stringstream.members

References:
- https://eel.is/c++draft/string.streams

show more ...


# 37dca605 29-Feb-2024 Louis Dionne <ldionne.2@gmail.com>

[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
th

[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

show more ...


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3
# d2ccf339 13-Feb-2024 Hristo Hristov <hghristov.rmm@gmail.com>

[libc++][sstream] Explicitly delete special member functions (#80254)

The standard declares the copy constructors and copy assign operators as
deleted.

References:
- https://eel.is/c++draft/str

[libc++][sstream] Explicitly delete special member functions (#80254)

The standard declares the copy constructors and copy assign operators as
deleted.

References:
- https://eel.is/c++draft/string.streams

show more ...


Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# f73bf45d 21-Jan-2024 bobsayshilol <bobsayshilol@live.co.uk>

[libc++] Fix typo in _LIBCPP_REMOVE_TRANSITIVE_INCLUDES (#78639)

Spotted by inspection when trialling out
`_LIBCPP_REMOVE_TRANSITIVE_INCLUDES`. No other instances of `_LIPCPP_`
were found in the r

[libc++] Fix typo in _LIBCPP_REMOVE_TRANSITIVE_INCLUDES (#78639)

Spotted by inspection when trialling out
`_LIBCPP_REMOVE_TRANSITIVE_INCLUDES`. No other instances of `_LIPCPP_`
were found in the repo.

show more ...


# 5351ded6 08-Jan-2024 Tacet <advenam.tacet@trailofbits.com>

[libc++] Remove usage of internal string function in sstream (#75858)

This function replaces a call to `__move_assign` (internal function)
with two calls to public member functions (`resize` and `e

[libc++] Remove usage of internal string function in sstream (#75858)

This function replaces a call to `__move_assign` (internal function)
with two calls to public member functions (`resize` and `erase`). The
order of calls is chosen for the best performance.

This change is required to [turn on ASan string annotations for short
strings](https://github.com/llvm/llvm-project/pull/75882) (Short String
Optimization - SSO).

The `std::basic_string` class's `void __move_assign(basic_string&&
__str, size_type __pos, size_type __len)` function operates on
uninitialized strings, where it is reasonable to assume that the memory
is not poisoned. However, in `sstream` this function is applied to
existing strings that already have poisoned memory.

String ASan annotations turned on here:
https://github.com/llvm/llvm-project/pull/72677

show more ...


# 9783f28c 18-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[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 benchmar

[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

show more ...


# 77a00c0d 05-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[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

[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.

show more ...


# b18a46e3 04-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[libc++][NFC] Add a few clang-format annotations (#74352)

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or becaus

[libc++][NFC] Add a few clang-format annotations (#74352)

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or because
the manually formatted code is significantly more readable than the
clang-formatted alternative. All in all, it seems like very few
annotations are required, which means that clang-format is doing a very
good job in most cases.

show more ...


# 4c198542 04-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[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_INLIN

[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.

show more ...


Revision tags: llvmorg-17.0.6
# 12563ea6 24-Nov-2023 philnik777 <nikolasklauser@berlin.de>

[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002)

This makes the conditionals quite a bit simpler to understand, since it
avoids double negatives and makes sure

[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002)

This makes the conditionals quite a bit simpler to understand, since it
avoids double negatives and makes sure we have <__availability>
included. For vendors which use availability macros, it also enforces
that they check when specific features are introduced and define the
macro for their platform appropriately.

show more ...


Revision tags: llvmorg-17.0.5, llvmorg-17.0.4
# 838f2890 17-Oct-2023 Amirreza Ashouri <ar.ashouri999@gmail.com>

[libc++] Eliminate extra allocations from `std::move(oss).str()` (#67294)

Add test coverage for the new behaviors, especially to verify that the
returned string uses the correct allocator.
Fixes htt

[libc++] Eliminate extra allocations from `std::move(oss).str()` (#67294)

Add test coverage for the new behaviors, especially to verify that the
returned string uses the correct allocator.
Fixes https://github.com/llvm/llvm-project/issues/64644

Migrated from https://reviews.llvm.org/D157776 — @philnik777 @pfusik
@ldionne @mordante
please take another look!

show more ...


Revision tags: llvmorg-17.0.3
# e9c101a7 16-Oct-2023 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++] Add missing <__availability> include


Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0
# c66d0b01 14-Sep-2023 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++] Recategorize additional instantiations in the dylib as availability macros

Adding additional instantiations to the dylib isn't actually an ABI break as long as programs targeting an older d

[libc++] Recategorize additional instantiations in the dylib as availability macros

Adding additional instantiations to the dylib isn't actually an ABI break as long as programs targeting an older dylib don't start to depend on them. Making additional instantiations a matter of availability allows us to add them without an ABI break.

Reviewed By: #libc, ldionne, Mordante

Spies: arichardson, ldionne, Mordante, libcxx-commits

Differential Revision: https://reviews.llvm.org/D154796

show more ...


Revision tags: llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3
# 090996f4 10-Aug-2023 Piotr Fusik <piotr@fusion-lang.org>

[libc++] Work around dynamic linking of stringstream::str() on Windows

Also `istringstream::str()` and `ostringstrem::str()`.

https://github.com/llvm/llvm-project/issues/40363 causes `str()`
to be

[libc++] Work around dynamic linking of stringstream::str() on Windows

Also `istringstream::str()` and `ostringstrem::str()`.

https://github.com/llvm/llvm-project/issues/40363 causes `str()`
to be dllimport'ed despite _LIBCPP_HIDE_FROM_ABI.
This is a temporary solution until #40363 is fixed.

Reviewed By: #libc, thakis, philnik

Differential Revision: https://reviews.llvm.org/D157602

show more ...


1234