| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whether an explicit instantiation declaration should be provided is not
a matter of availability markup.
This problem is exemplified by the fact that some tests were incorrectly
marked as XFAIL when they should instead have been using the definition
of streams from the headers, and hence passing, and that, regardless of
whether visibility annotations are enabled.
llvm-svn: 348436
|
|
|
|
|
|
|
|
|
|
|
|
| |
That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many
weeks now, so we're actually replacing uses of it for uses of
_LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly.
This should not change or break anything since the two macros are
100% equivalent, unless somebody is (incorrectly!) relying on
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined.
llvm-svn: 344641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_LIBCPP_INLINE_VISIBILITY
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_LIBCPP_INLINE_VISIBILITY"
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
llvm-svn: 336382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336369
|
|
|
|
|
|
| |
traits match the character type. This is a requirement on the user - now we get consistent failures at compile time instead of incomprehensible error messages or runtime failures. This is also LWG#2994 - not yet adopted.
llvm-svn: 323945
|
|
|
|
|
|
| |
thanks to Jonathan Wakely for the report
llvm-svn: 313031
|
|
|
|
|
|
| |
INT_MAX, since it only takes an int. Related to, but not quite the same as PR33725
llvm-svn: 308880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compatibility
Summary:
GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'.
```
// RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
// RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
#define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline))
template <class T>
struct Foo {
void foo();
void bar();
};
template <class T>
void Foo<T>::foo() {}
template <class T>
inline INLINE_VISIBILITY
void Foo<T>::bar() {}
template struct Foo<int>;
```
This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated).
Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline` therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors).
This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`.
After applying this patch GCC dylibs now contain:
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE`
* `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl`
* `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw`
This patch has no effect on Clang based builds.
Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF
Subscribers: beanz, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24600
llvm-svn: 281681
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Patch by Laman Sole <laxman.g@partner.samsung.com>, Sebastian Pop
<s.pop@samsung.com>, Aditya Kumar <aditya.k7@samsung.com>
Differential Revision: http://reviews.llvm.org/D21103
llvm-svn: 272401
|
|
|
|
|
|
| |
iostreams."
llvm-svn: 257193
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
instead of one at a time. References PR#10193
llvm-svn: 229866
|
|
|
|
|
|
| |
explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.
llvm-svn: 188192
|
|
|
|
|
|
| |
two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute.
llvm-svn: 176593
|
|
|
|
|
|
| |
intended for the clients of libc++, not the libc++ build. The dylib should always contain the extern templates. To disable the client needs to put -D'_LIBCPP_EXTERN_TEMPLATE(...)=' on the command line.
llvm-svn: 167486
|
|
|
|
|
|
| |
when calling overflow to correctly handle negative signed character types. This fixes http://llvm.org/bugs/show_bug.cgi?id=14074.
llvm-svn: 165884
|
|
|
|
| |
llvm-svn: 145624
|
|
|
|
| |
llvm-svn: 142235
|
|
|
|
| |
llvm-svn: 134190
|
|
|
|
| |
llvm-svn: 119395
|
|
|
|
| |
llvm-svn: 114671
|
|
|
|
| |
llvm-svn: 111750
|
|
|
|
| |
llvm-svn: 103516
|
|
llvm-svn: 103490
|