Summary:
This patch fixes http://llvm.org/PR31938. The description below is copy/pasted from the bug:
The standard says:
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT>>
class basic_string {
using value_type = typename traits::char_type;
// ...
basic_string(const charT* s, const Allocator& a = Allocator());
};
libc++ actually chooses to declare the constructor as
basic_string(const value_type* s, const Allocator& a = Allocator());
The implicit deduction guides from class template argument deduction make what was previously an implementation detail visible:
std::basic_string s = "foo"; // error, can't deduce charT.
The constructor in question is in the libc++ DSO, but fortunately it looks like fixing this will not result in an ABI break.
@rsmith How does this look? I did more than just the constructors mentioned in the PR, but IDK how far to take it.
Reviewers: mclow.lists, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D29863
llvm-svn: 295393
Visible definitions for basic_string::assign are sometimes emitted in
the dylib depending on the version of LLVM used to compile libc++.
This can cause the check-cxx-abilist target to fail.
This patch attempts marks the basic_string::assign templates as inline
to prevent this. That way the export list is consistent across LLVM
versions.
llvm-svn: 294100
When support for `basic_string_view` was added to string it also
added new assignment operators from `basic_string_view`. These caused
ambiguity when assigning from a braced initializer. This patch fixes
that regression by making the basic_string_view assignment operator
rank lower in overload resolution by making it a template.
llvm-svn: 292276
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
Adding both 'inline' and 'always_inline' to the destructor has been contentious.
However most of the performance benefits can be gained by only adding 'inline',
and there is no reason to hold up that change while discussing the other.
llvm-svn: 285538
path uses string::append to construct, append, and concatenate paths. Unfortunatly
string::append has a strong exception safety guaranteed and if it can't prove
that the iterator operations don't throw then it will allocate a temporary
string copy to append to. However this extra allocation and copy is very
undesirable for path which doesn't have the same exception guarantees.
To work around this this patch adds string::__append_forward_unsafe which exposes
the std::string::append interface for forward iterators without enforcing
that the iterator is noexcept.
llvm-svn: 285532
Author: laxmansole
Reviewers: howard.hinnant
mclow.lists
Subscribers: EricWF, flyingforyou, evandro
Differential Revision: https://reviews.llvm.org/D25624
Reapplying the patch as the bug https://llvm.org/bugs/show_bug.cgi?id=30341 is fixed.
Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string().
Worked in collaboration with Aditya Kumar.
llvm-svn: 285456
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
llvm-svn: 281673
This patch causes a couple of issues:
1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++
bug it breaks the LLVM build using libc++. Reverting this patch is only
a temporary workaround until Clang is fixed.
2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC.
Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line
definition when compiling the dylib. This causes the externally instantiated
~basic_string symbol to have hidden visibility.
This patch should be recommitted after addressing (1) and (2). (2) can be fixed
by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as
__attribute__((visibility("default"), always_inline)) as opposed to
_LIBCPP_INLINE_VISIBILITY which makes the symbol hidden.
llvm-svn: 281562
Author: laxmansole
Reviewers: howard.hinnant
mclow.lists
Subscribers: EricWF, flyingforyou, evandro
Differential Revision: https://reviews.llvm.org/D22834
Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string().
Worked in collaboration with Aditya Kumar.
llvm-svn: 280944
basic_string's constructor calls init which was not getting inlined. This
prevented optimization of const string as init would appear as a call in between
a string's def and use.
Patch by Laxman Sole and Aditya Kumar.
Differential Revision: https://reviews.llvm.org/D22782
llvm-svn: 278356
This change moves visibility attributes from out-of-class method
definitions to in-class declaration. This is needed for a switch to
attribute((internal_linkage)) (see http://reviews.llvm.org/D13925)
which can only appear on the first declaration.
This change does not touch istream/ostream/streambuf. They are
handled separately in http://reviews.llvm.org/D14409.
llvm-svn: 252385
C++ macros and CMake options that specify the default ABI version of
the library, and can be overridden to pick up new ABI-changing
features.
llvm-svn: 250254
Summary:
This patch optimizes basic_string::compare to use strcmp when the default char_traits has been given.
See PR19900 for more information. https://llvm.org/bugs/show_bug.cgi?id=19900
Reviewers: mclow.lists
Subscribers: bkramer, cfe-commits
Differential Revision: http://reviews.llvm.org/D12355
llvm-svn: 246266
Although CMake adds warning flags, they are ignored in the libc++ headers
because the headers '#pragma system header' themselves.
This patch disables the system header pragma when building libc++ and fixes
the warnings that arose.
The warnings fixed were:
1. <memory> - anonymous structs are a GNU extension
2. <functional> - anonymous structs are a GNU extension.
3. <__hash_table> - Embedded preprocessor directives have undefined behavior.
4. <string> - Definition is missing noexcept from declaration.
5. <__std_stream> - Unused variable.
llvm-svn: 242623
Summary:
An evil user might overload operator comma. Use a void cast to make sure any user overload is not selected.
Modify all the test iterators to define operator comma.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5929
llvm-svn: 220706
GCC 4.9 fails to inline these functions at -O1 because they are used
indirectly. Declare them as inline instead of always_inline. Discussion
in GCC bugreport: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63220
llvm-svn: 217961
Things done in this patch:
1. Make __debug include __config since it uses macros from it.
2. The current method of defining _LIBCPP_ASSERT is prone to redefinitions. Move
the null _LIBCPP_ASSERT definition into the __debug header to prevent this.
3. Remove external <__debug> include gaurds. <__debug> guards almost all of its
contents internally. There is no reason to be doing it externally.
This patch should not change any functionality.
llvm-svn: 215332
The patch touches these files:
locale
array
deque
new
string
utility
vector
__bit_reference
__split_buffer
locale_win32.h
There is no intended functionality change and it is expected that reversing the position of the inline keyword with regard to the other keywords does not change the meaning of anything, least not for apple/Linux etc.
It is intended to make libcxx more consistent with itself and to prevent the 1000 or so
"inline.cpp(3) : warning C4141: 'inline' : used more than once" warnings that MS's cl.exe compiler emits without this patch, i.e. if inline is not the first keyword before a function name etc.
Prefer "inline [other inline related keyword]" over "[other related keyword] inline".
After this patch, libcxx should be consistent to this pattern.
llvm-svn: 191987
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
llvm-svn: 187593
are two motivations for this.
First, this allows users who are specializing __gnu_ext::hash to
continue doing so without changing their code.
Second, SGI specifies hash overloads for char* and const char* that
perform a hash of the string, not of the pointer.
In order to support this, the hashing code for string is factored out.
llvm-svn: 136539
Eric Fiselier