History log of /llvm-project-15.0.7/libcxx/include/istream (Results 1 – 25 of 78)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6
# 3cd4531b 10-Jun-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize <iterator> includes

Reviewed By: ldionne, #libc

Spies: libcxx-commits, wenlei

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


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2
# 2ae52326 08-Jun-2021 Louis Dionne <[email protected]>

[libc++] Towards a simpler extern template story in libc++

The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for

[libc++] Towards a simpler extern template story in libc++

The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).

This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.

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

show more ...


# 385cc25a 25-Mar-2022 Louis Dionne <[email protected]>

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

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

show more ...


# e39095a3 03-Mar-2022 Louis Dionne <[email protected]>

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.

After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.

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

show more ...


# fa6b9e40 02-Feb-2022 Arthur O'Dwyer <[email protected]>

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

show more ...


# feb80aa9 08-Dec-2021 Nikolas Klauser <[email protected]>

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commit

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commits

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

show more ...


# eb8650a7 17-Nov-2021 Louis Dionne <[email protected]>

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...


# f4c1258d 23-Aug-2021 Louis Dionne <[email protected]>

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

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

show more ...


# a8d1182f 15-Jun-2021 Arthur O'Dwyer <[email protected]>

[libc++] Remove some _LIBCPP_CXX03_LANG from iostreams headers.

With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things th

[libc++] Remove some _LIBCPP_CXX03_LANG from iostreams headers.

With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.

Clang's C++03 mode does not support delegating constructors.

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

show more ...


# 58549680 15-Jun-2021 Arthur O'Dwyer <[email protected]>

[libc++] Enable the rvalue overloads of operator<< and operator>> even in C++03.

Continuing to eliminate no-longer-needed uses of _LIBCPP_CXX03_LANG.

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

[libc++] Enable the rvalue overloads of operator<< and operator>> even in C++03.

Continuing to eliminate no-longer-needed uses of _LIBCPP_CXX03_LANG.

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

show more ...


# 6adbc83e 05-Jun-2021 Christopher Di Bella <[email protected]>

[libcxx][modularisation] moves <utility> content out of <type_traits>

Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges`

[libcxx][modularisation] moves <utility> content out of <type_traits>

Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`

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

show more ...


# 317e92a3 15-Jun-2021 Arthur O'Dwyer <[email protected]>

[libc++] Enable `explicit` conversion operators, even in C++03 mode.

C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets u

[libc++] Enable `explicit` conversion operators, even in C++03 mode.

C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.

Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.

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

show more ...


Revision tags: llvmorg-12.0.1-rc1
# bfbd73f8 19-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Alphabetize and include-what-you-use. NFCI.

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


# ab3fcc50 10-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] s/_VSTD::declval/declval/g. NFCI.


# 4cd6ca10 20-Apr-2021 Louis Dionne <[email protected]>

[libc++] NFC: Normalize `#endif //` comment indentation


Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1
# 527a7fdf 24-Nov-2020 Bruce Mitchener <[email protected]>

[libc++] Replace several uses of 0 by nullptr

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


# ce565861 22-Oct-2020 Louis Dionne <[email protected]>

[libc++] Drop old workaround for iostreams instantiations missing from the dylib

On old Apple platforms (pre 10.9), we couldn't rely on the iostreams
explicit instantiations being part of the dylib.

[libc++] Drop old workaround for iostreams instantiations missing from the dylib

On old Apple platforms (pre 10.9), we couldn't rely on the iostreams
explicit instantiations being part of the dylib. However, we don't
support back-deploying to such old deployment targets anymore, so the
workaround can be dropped.

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4
# c90dee1e 23-Sep-2020 Louis Dionne <[email protected]>

[libc++] Re-apply fdc41e11f (LWG1203) without breaking the C++11 build

fdc41e11f was reverted in e46c1def5 because it broke the C++11 build.
We shouldn't be using enable_if_t in C++11, instead we mu

[libc++] Re-apply fdc41e11f (LWG1203) without breaking the C++11 build

fdc41e11f was reverted in e46c1def5 because it broke the C++11 build.
We shouldn't be using enable_if_t in C++11, instead we must use
enable_if<...>::type.

show more ...


# e46c1def 23-Sep-2020 Raphael Isemann <[email protected]>

Revert "[libc++] Implement LWG1203"

This reverts commit fdc41e11f9687a50c97e2a59663bf2d541ff5489. It causes the
libcxx/modules/stds_include.sh.cpp test to fail with:
libcxx/include/ostream:1039:45:

Revert "[libc++] Implement LWG1203"

This reverts commit fdc41e11f9687a50c97e2a59663bf2d541ff5489. It causes the
libcxx/modules/stds_include.sh.cpp test to fail with:
libcxx/include/ostream:1039:45: error: no template named 'enable_if_t'; did you mean 'enable_if'?
template <class _Stream, class _Tp, class = enable_if_t<

Still investigating what's causing this and reverting in the meantime to get
the bots green again.

show more ...


# fdc41e11 22-Sep-2020 Louis Dionne <[email protected]>

[libc++] Implement LWG1203

Libc++ had an issue where nonsensical code like

decltype(std::stringstream{} << std::vector<int>{});

would compile, as long as you kept the expression inside decltype

[libc++] Implement LWG1203

Libc++ had an issue where nonsensical code like

decltype(std::stringstream{} << std::vector<int>{});

would compile, as long as you kept the expression inside decltype in
an unevaluated operand. This turned out to be that we didn't implement
LWG1203, which clarifies what we should do in that case.

rdar://58769296

show more ...


Revision tags: llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# fc4486c2 20-Aug-2019 Louis Dionne <[email protected]>

[libc++] Implement LWG 3199

Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.

Reviewers: mclow.lists, EricWF

Su

[libc++] Implement LWG 3199

Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.

Reviewers: mclow.lists, EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

llvm-svn: 369422

show more ...


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1
# 396145d0 05-Apr-2019 Louis Dionne <[email protected]>

[libc++] Fix error flags and exceptions propagated from input stream operations

Summary:
This is a re-application of r357533 and r357531. They had been reverted
because we thought the commits broke

[libc++] Fix error flags and exceptions propagated from input stream operations

Summary:
This is a re-application of r357533 and r357531. They had been reverted
because we thought the commits broke the LLDB data formatters, but it
turns out this was because only r357531 had been included in the CI
run.

Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.

This effectively implements the wording in p1264r0. It hasn't been voted
into the Standard yet, however there is wide agreement that the fix is
correct and it's just a matter of time before the fix is standardized.

PR21586
PR15949
rdar://problem/15347558

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

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

llvm-svn: 357775

show more ...


# 38b7e748 02-Apr-2019 Louis Dionne <[email protected]>

Revert "[libc++] Fix error flags and exceptions propagated from input stream operations"

This reverts commits r357533 and r357531, which broke the LLDB
data formatters. I'll hold off until we know h

Revert "[libc++] Fix error flags and exceptions propagated from input stream operations"

This reverts commits r357533 and r357531, which broke the LLDB
data formatters. I'll hold off until we know how to fix the data
formatters accordingly.

llvm-svn: 357536

show more ...


# 00f6cfe9 02-Apr-2019 Louis Dionne <[email protected]>

[libc++] Fix build when exceptions are turned off

llvm-svn: 357533


# 17547743 02-Apr-2019 Louis Dionne <[email protected]>

[libc++] Fix error flags and exceptions propagated from input stream operations

Summary:
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is

[libc++] Fix error flags and exceptions propagated from input stream operations

Summary:
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.

I will submit a paper in San Diego to clarify the Standard such that the
interpretation used in this commit (and other implementations) is the only
possible one.

PR21586
PR15949
rdar://problem/15347558

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

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

llvm-svn: 357531

show more ...


1234