This commit adds new explicit instantiations for some classes in <iostream>
in the library. This is done after noticing that many programs that use
streams end up containing weak definitions of these classes, which has a
negative impact on both code size and load times (due to the need to
resolve weak symbols at load time). Note that we are just adding the
additional explicit instantiations for the `char` specializations, since
the `wchar_t` specializations are not used as often, and as a result there
wouldn't be a clear benefit.
This change is not an ABI break, since we are just adding additional
symbols.
Differential Revision: https://reviews.llvm.org/D90677
We don't support any compiler that doesn't support variadics and rvalue
references in C++03 mode, so these workarounds can be dropped. There's
still *a lot* of cruft related to these workarounds, but I try to tackle
a bit of it here and there.
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
As a result of this change, the basic_stringbuf constructor that
takes a mode ends up leaving __hm_ set to 0, causing the comparison
"__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused
the function to incorrectly return -1. The fix is to account for the
possibility of __hm_ being 0 when computing the distance from __hm_
to the start of the string.
Differential Revision: https://reviews.llvm.org/D41319
llvm-svn: 321124
Summary:
[libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf
constructor that takes ios_base::openmode as follows:
Effects: Constructs an object of class basic_stringbuf, initializing the
base class with basic_streambuf(), and initializing mode with which.
Postconditions: str() == "".
The default constructor of basic_streambuf shall initialize all its
pointer member objects to null pointers [streambuf.cons]p1.
Currently libc++ calls "str(string_type());" in the aforementioned constructor
setting basic_streambuf's pointers to a non-null value.
This patch removes the call (note that the postcondition str() == ""
remains valid because __str_ is default-initialized) and adds a test checking
that the basic_streambuf's pointers are null after construction.
Thanks Mikhail Maltsev for the patch.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40707
llvm-svn: 320604
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).
This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.
llvm-svn: 291035
No point in pretending that these methods are hidden - they are
actually exported from libc++.so. Extern template declarations make
them part of libc++ ABI.
This patch does not change libc++.so export list (at least on Linux).
llvm-svn: 255177
Louis Dionne