maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/lib/abi/CHANGELOG.TXT

327 lines
16 KiB
Plaintext
Raw Normal View History

Add ABI Changelog and current symbol list for Linux llvm-svn: 284185
2016-10-14 10:27:44 +08:00
ABI Changelog
==============
This changelog contains information about ABI changes in libc++. Specifically
the addition and deletion of symbols from the libc++ dylib.
Each entry should start with the revision number followed by a description of
the change. The entry should contain a summary of the ABI changes made,
including what symbols were added, removed, or changed.
To generate a summary use "sym_diff.py" diffing against the appropriate ABI list.
Afterwards the ABI list should be updated to include the new changes.
New entries should be added directly below the "Version" header.
Update ABI lists after change in r333467. r333467 updated the symbols exported by libc++.so/dylib by changing the ODR usage of __uncaught_exception/__uncaught_exceptions. This should not be a breaking change. llvm-svn: 333481
2018-05-30 07:52:14 +08:00
-----------
Correct ABI list change wrongly advertised as being in the 7.0 release llvm-svn: 345670
2018-10-31 07:24:02 +08:00
Version 8.0
Update ABI lists after change in r333467. r333467 updated the symbols exported by libc++.so/dylib by changing the ODR usage of __uncaught_exception/__uncaught_exceptions. This should not be a breaking change. llvm-svn: 333481
2018-05-30 07:52:14 +08:00
-----------
[NFC] Add missing revision for removal of bad_array_length in ABI changelog llvm-svn: 352513
2019-01-30 00:30:11 +08:00
* r347903 - Remove std::bad_array_length
[libcxx] Remove bad_array_length Summary: std::bad_array_length was added by n3467, but this never made it into C++. This commit removes the definition of std::bad_array_length from the headers AND from the shared library. See the comments in the ABI changelog for details about the ABI implications of this change. Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF Subscribers: christof, jkorous, libcxx-commits Differential Revision: https://reviews.llvm.org/D54804 llvm-svn: 347903
2018-11-30 03:44:57 +08:00
The change removes the definition of std::bad_array_length (which never made
it into the standard) from the headers and the dylib. This is technically an
ABI break because the symbols are shipped starting with mac OSX 10.13, however
users couldn't be relying on the functionality because it is marked as being
unavailable using Clang's availability attribute.
x86_64-apple-darwin16.0
-----------------------
Symbol removed: __ZNKSt16bad_array_length4whatEv
Symbol removed: __ZNKSt16bad_array_length4whatEv
Symbol removed: __ZNSt16bad_array_lengthC1Ev
Symbol removed: __ZNSt16bad_array_lengthC1Ev
Symbol removed: __ZNSt16bad_array_lengthC2Ev
Symbol removed: __ZNSt16bad_array_lengthC2Ev
Symbol removed: __ZNSt16bad_array_lengthD0Ev
Symbol removed: __ZNSt16bad_array_lengthD0Ev
Symbol removed: __ZNSt16bad_array_lengthD1Ev
Symbol removed: __ZNSt16bad_array_lengthD1Ev
Symbol removed: __ZNSt16bad_array_lengthD2Ev
Symbol removed: __ZNSt16bad_array_lengthD2Ev
Symbol removed: __ZTISt16bad_array_length
Symbol removed: __ZTISt16bad_array_length
Symbol removed: __ZTSSt16bad_array_length
Symbol removed: __ZTSSt16bad_array_length
Symbol removed: __ZTVSt16bad_array_length
Symbol removed: __ZTVSt16bad_array_length
[NFC][libcxx] Add revision number to ABI changelog llvm-svn: 347396
2018-11-22 00:27:14 +08:00
* r347395 - Making libc++ build under -fvisibility=hidden on Linux
[libcxx] Make sure we can build with -fvisibility=hidden on Linux Summary: This commit marks a few functions as hidden and removes them from the ABI list on Linux such that libc++ can be built with -fvisibility=hidden. The functions marked as hidden by this patch were exported from the shared object only because they were implicitly instantiated function templates. It is safe to stop exporting those symbols from the shared object because nobody could actually depend on them: implicit instantiations are not taken from shared objects. The symbols removed in this commit are basically the same that had been removed in https://reviews.llvm.org/D53868, but that patch had to be reverted because it broke the build (because the functions were not marked as hidden like this patch does). Reviewers: EricWF, mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D54639 llvm-svn: 347395
2018-11-22 00:24:46 +08:00
The change marks several function templates as hidden. This removes symbols
from the shared library, but this is not an ABI break because it's impossible
for programs linking against libc++.so to actually depend on that symbol.
The reason is that the symbol is exported from the shared library through
an implicit instantiation present in the shared object itself only. Furthermore,
if a user's shared object was implicitly instantiating one of these functions,
marking that symbol as hidden would not be an ABI break for them because none
of their users could actually be using the symbol in their dylib (because
it's an implicit instantiation).
x86_64-linux-gnu
----------------
Symbol removed: _ZNSt3__125__num_get_signed_integralIlEET_PKcS3_Rji
Symbol removed: _ZNSt3__125__num_get_signed_integralIxEET_PKcS3_Rji
Symbol removed: _ZNSt3__127__num_get_unsigned_integralIjEET_PKcS3_Rji
Symbol removed: _ZNSt3__127__num_get_unsigned_integralImEET_PKcS3_Rji
Symbol removed: _ZNSt3__127__num_get_unsigned_integralItEET_PKcS3_Rji
Symbol removed: _ZNSt3__127__num_get_unsigned_integralIyEET_PKcS3_Rji
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIaaEEPaEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIccEEPcEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIddEEPdEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIffEEPfEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIhhEEPhEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIiiEEPiEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIjjEEPjEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIllEEPlEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessImmEEPmEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIssEEPsEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIttEEPtEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIwwEEPwEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIxxEEPxEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__17__sort5IRNS_6__lessIyyEEPyEEjT0_S5_S5_S5_S5_T_
Symbol removed: _ZNSt3__1plIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_12basic_stringIT_T0_T1_EERKS9_PKS6_
Symbol removed: _ZSt18make_exception_ptrINSt3__112future_errorEESt13exception_ptrT_
* r345260 - Making libc++ build under -fvisibility=hidden on Mac OS
[libc++] Make sure we can build libc++ with -fvisibility=hidden Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
2018-10-25 20:13:43 +08:00
The change marks __thread_specific_ptr<__thread_struct>::__at_thread_exit(void*)
with hidden visibility. This removes a symbol from the shared libraries,
however this is not an ABI break because it's impossible for programs linking
against libc++.dylib to actually depend on that symbol. The reason is that
the symbol is exported from the shared library through an implicit
instantiation present in the dylib itself only. Furthermore, if a user's
dylib was implicitly instantiating __thread_specific_ptr<T>::__at_thread_exit
(because it's defined in the headers), marking that symbol as hidden would
not be an ABI break for them because none of their users could actually be
using the symbol in their dylib (because it's an implicit instantiation).
This change also marks __start_std_streams as hidden -- this variable is
only required to initialize the streams, and nobody should depend on it
from outside the dylib.
x86_64-linux-gnu
----------------
Symbol removed: _ZNSt3__121__thread_specific_ptrINS_15__thread_structEE16__at_thread_exitEPv
Symbol removed: _ZNSt3__119__start_std_streamsE
x86_64-apple-darwin16.0
-----------------------
Symbol removed: __ZNSt3__221__thread_specific_ptrINS_15__thread_structEE16__at_thread_exitEPv
Symbol removed: __ZNSt3__119__start_std_streamsE
Correct ABI list change wrongly advertised as being in the 7.0 release llvm-svn: 345670
2018-10-31 07:24:02 +08:00
-----------
Version 7.0
-----------
[libc++] Make sure we can build libc++ with -fvisibility=hidden Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
2018-10-25 20:13:43 +08:00
Document new symbols for __u64toa and __u32toa Summary: They are introduced in r338479; their Linux ABI changes are recorded in r338486. TODO: Record the Mac OS X ABI changes. Reviewers: EricWF Reviewed By: EricWF Subscribers: christof, ldionne, libcxx-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D52391 llvm-svn: 342810
2018-09-23 02:05:28 +08:00
* r338479 - Elementary string conversions for integral types
The change emits __u64toa and __u32toa under std::__1::__itoa.
x86_64-linux-gnu
----------------
Symbol added: _ZNSt3__16__itoa8__u64toaEmPc
Symbol added: _ZNSt3__16__itoa8__u32toaEjPc
x86_64-apple-darwin16.0
-----------------------
[libcxx] Document new symbols __u64toa and __u32toa on Darwin Summary: This is the counterpart for https://reviews.llvm.org/D50130 and https://reviews.llvm.org/D52391 on Darwin. Reviewers: EricWF Subscribers: christof, dexonsmith, cfe-commits, libcxx-commits, lichray Differential Revision: https://reviews.llvm.org/D52396 llvm-svn: 342849
2018-09-24 05:10:06 +08:00
Symbol added: __ZNSt3__16__itoa8__u64toaEyPc
Symbol added: __ZNSt3__16__itoa8__u32toaEjPc
Document new symbols for __u64toa and __u32toa Summary: They are introduced in r338479; their Linux ABI changes are recorded in r338486. TODO: Record the Mac OS X ABI changes. Reviewers: EricWF Reviewed By: EricWF Subscribers: christof, ldionne, libcxx-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D52391 llvm-svn: 342810
2018-09-23 02:05:28 +08:00
Update ABI lists after change in r333467. r333467 updated the symbols exported by libc++.so/dylib by changing the ODR usage of __uncaught_exception/__uncaught_exceptions. This should not be a breaking change. llvm-svn: 333481
2018-05-30 07:52:14 +08:00
* r333467 - Fix embarrasing typo in uncaught_exceptions.
This bug caused __uncaught_exception to be ODR used instead of
__uncaught_exceptions. This change is non-ABI breaking because the symbols
for std::uncaught_exception and std::uncaught_exceptions haven't changed,
and because users shouldn't be depending directly on libc++ exporting
__uncaught_exception/__uncaught_exceptions.
All Platforms
----------------
SYMBOL REMOVED: __cxa_uncaught_exception
Symbol added: __cxa_uncaught_exceptions
[libc++] Mark some std::num_get method templates inline D29157 will make explicit template instantiations expand to default visibility, at which point these method templates will need to be explicitly marked hidden visibility to avoid leaking into other DSOs. Unfortunately, because of clang PR32114, they must be marked inline (in conjunction with `-fvisibility-inlines-hidden`) to actually hide them, since clang doesn't respect the hidden visibility annotation. Since this involves an ABI change, mark these methods inline in a separate change, so that the ABI changes can be reviewed separately and verified to be safe. Differential Revision: https://reviews.llvm.org/D30523 llvm-svn: 296729
2017-03-02 10:51:27 +08:00
-----------
Version 5.0
-----------
Update changelog revision llvm-svn: 313501
2017-09-18 05:00:27 +08:00
* r313500 - Fix undefined "___cxa_deleted_virtual" symbol in macosx
ABI: Fix for undefined "___cxa_deleted_virtual" symbol in MacOSX Patch from Eddie Elizondo. Reviewed as D37830 (https://reviews.llvm.org/D37830). On MacOSX the following program: struct S { virtual void f() = delete; }; int main() { new S; } Fails with the following error: Undefined symbols for architecture x86_64: "___cxa_deleted_virtual" This adds a fix to export the needed symbols. Test: > lit -sv test/libcxx/language.support/cxa_deleted_virtual.pass.cpp > Testing Time: 0.21s > Expected Passes : 1 llvm-svn: 313500
2017-09-18 04:59:43 +08:00
x86_64-linux-gnu
----------------
No changes
x86_64-apple-darwin16.0
-----------------------
Symbol added: ___cxa_deleted_virtual
[libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export members When building libc++ with hidden visibility, we want explicit template instantiations to export members. This is consistent with existing Windows behavior, and is necessary for clients to be able to link against a hidden visibility built libc++ without running into lots of missing symbols. An unfortunate side effect, however, is that any template methods of a class with an explicit instantiation will get default visibility when instantiated, unless the methods are explicitly marked inline or hidden visibility. This is not desirable for clients of libc++ headers who wish to control their visibility, and led to PR30642. Annotate all problematic methods with an explicit visibility specifier to avoid this. The problematic methods were found by running https://github.com/smeenai/bad-visibility-finder against the libc++ headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS macro, which was created for this purpose. It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally intended to expand to default visibility, and was changed to expanding to default type visibility to fix PR30642. The visibility macro documentation was not updated accordingly, however, so this change makes the macro consistent with its documentation again, while explicitly fixing the methods which resulted in that PR. Differential Revision: https://reviews.llvm.org/D29157 llvm-svn: 296731
2017-03-02 11:02:50 +08:00
* r296729 - Remove std::num_get template methods which should be inline
[libc++] Mark some std::num_get method templates inline D29157 will make explicit template instantiations expand to default visibility, at which point these method templates will need to be explicitly marked hidden visibility to avoid leaking into other DSOs. Unfortunately, because of clang PR32114, they must be marked inline (in conjunction with `-fvisibility-inlines-hidden`) to actually hide them, since clang doesn't respect the hidden visibility annotation. Since this involves an ABI change, mark these methods inline in a separate change, so that the ABI changes can be reviewed separately and verified to be safe. Differential Revision: https://reviews.llvm.org/D30523 llvm-svn: 296729
2017-03-02 10:51:27 +08:00
These functions should never have had visible definitions in the dylib but
since they were previously not specified with 'inline' they accidentally
got emitted. This change is non-ABI breaking because every "linkage unit"
must contain its own definition.
x86_64-linux-gnu
----------------
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE15__do_get_signedIlEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE15__do_get_signedIxEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE17__do_get_unsignedIjEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE17__do_get_unsignedImEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE17__do_get_unsignedItEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE17__do_get_unsignedIyEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE23__do_get_floating_pointIdEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE23__do_get_floating_pointIeEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE23__do_get_floating_pointIfEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE15__do_get_signedIlEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE15__do_get_signedIxEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE17__do_get_unsignedIjEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE17__do_get_unsignedImEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE17__do_get_unsignedItEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE17__do_get_unsignedIyEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE23__do_get_floating_pointIdEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE23__do_get_floating_pointIeEES4_S4_S4_RNS_8ios_baseERjRT_
SYMBOL REMOVED: _ZNKSt3__17num_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwEEEEE23__do_get_floating_pointIfEES4_S4_S4_RNS_8ios_baseERjRT_
x86_64-apple-darwin16.0
-----------------------
No changes
Add ABI Changelog and current symbol list for Linux llvm-svn: 284185
2016-10-14 10:27:44 +08:00
-----------
Version 4.0
-----------
Fix debug mode build w/o exceptions llvm-svn: 290652
2016-12-28 13:20:27 +08:00
* r290651 - Add _LIBCPP_ASSERT debug handling functions
Implement a throwing version of _LIBCPP_ASSERT. This patch implements changes to allow _LIBCPP_ASSERT to throw on failure instead of aborting. The main changes needed to do this are: 1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer instead of calling abort directly. Additionally this patch implements two handler functions, one which aborts and another that throws an exception. 2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which contain _LIBCPP_ASSERT. This is required in order to prevent assertion failures throwing through a noexcept function. This macro has no effect unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined. Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of debug mode. Currently we can only have one test case per file, since the test case will cause the program to abort. Testing debug mode this way would require thousands of test files, most of which would be 95% boiler plate. I don't think this is a feasible strategy. Fortunately using a throwing debug handler solves these issues. Additionally this patch rewrites the documentation for debug mode. llvm-svn: 290651
2016-12-28 12:58:52 +08:00
All Platforms
-------------
Symbol added: _ZNSt3__124__libcpp_debug_exceptionC2ERKNS_19__libcpp_debug_infoE
Symbol added: _ZNSt3__124__libcpp_debug_exceptionD1Ev
Symbol added: _ZTINSt3__124__libcpp_debug_exceptionE
Symbol added: _ZNSt3__129__libcpp_throw_debug_functionERKNS_19__libcpp_debug_infoE
Symbol added: _ZNSt3__124__libcpp_debug_exceptionD2Ev
Symbol added: _ZNSt3__129__libcpp_abort_debug_functionERKNS_19__libcpp_debug_infoE
Symbol added: _ZNSt3__124__libcpp_debug_exceptionC2ERKS0_
Symbol added: _ZNSt3__124__libcpp_debug_exceptionC1Ev
Symbol added: _ZNSt3__124__libcpp_debug_exceptionC1ERKNS_19__libcpp_debug_infoE
Symbol added: _ZNSt3__124__libcpp_debug_exceptionC2Ev
Symbol added: _ZTSNSt3__124__libcpp_debug_exceptionE
Symbol added: _ZNSt3__123__libcpp_debug_functionE
Symbol added: _ZNKSt3__124__libcpp_debug_exception4whatEv
Symbol added: _ZNSt3__124__libcpp_debug_exceptionC1ERKS0_
Symbol added: _ZNSt3__124__libcpp_debug_exceptionD0Ev
Symbol added: _ZTVNSt3__124__libcpp_debug_exceptionE
Symbol added: _ZNSt3__127__libcpp_set_debug_functionEPFvRKNS_19__libcpp_debug_infoEE
Update ABI lists for <variant> llvm-svn: 288550
2016-12-03 07:11:28 +08:00
* r288547 - Implement C++17 <variant>
All Platforms
-------------
Symbol added: _ZTVSt18bad_variant_access
Symbol added: _ZTISt18bad_variant_access
Symbol added: _ZTSSt18bad_variant_access
Symbol added: _ZNKSt18bad_variant_access4whatEv
[libc++] Mark some std::num_get method templates inline D29157 will make explicit template instantiations expand to default visibility, at which point these method templates will need to be explicitly marked hidden visibility to avoid leaking into other DSOs. Unfortunately, because of clang PR32114, they must be marked inline (in conjunction with `-fvisibility-inlines-hidden`) to actually hide them, since clang doesn't respect the hidden visibility annotation. Since this involves an ABI change, mark these methods inline in a separate change, so that the ABI changes can be reviewed separately and verified to be safe. Differential Revision: https://reviews.llvm.org/D30523 llvm-svn: 296729
2017-03-02 10:51:27 +08:00
* r285537 - Remove std::string::append template methods which should be inline
Remove additional function template definitions from the dylib llvm-svn: 285537
2016-10-31 11:40:29 +08:00
These functions should never have had visible definitions in the dylib but
since they were previously not specified with 'inline' they accidentally
got emitted. This change is non-ABI breaking because every "linkage unit"
must contain its own definition.
x86_64-linux-gnu
----------------
SYMBOL REMOVED: _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6appendIPcEENS_9enable_ifIXaasr21__is_forward_iteratorIT_EE5valuesr38__libcpp_string_gets_noexcept_iteratorIS9_EE5valueERS5_E4typeES9_S9_
SYMBOL REMOVED: _ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6appendIPwEENS_9enable_ifIXaasr21__is_forward_iteratorIT_EE5valuesr38__libcpp_string_gets_noexcept_iteratorIS9_EE5valueERS5_E4typeES9_S9_
x86_64-apple-darwin16.0
-----------------------
No changes
[libcxx] Build with -fvisibility-inlines-hidden -- Remove 20 inline definitions from the dylib Summary: This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib. On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them. Also could a FreeBSD maintainer comment on the ABI compatibility of this patch? Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim Subscribers: beanz, mgorny, cfe-commits, modocache Differential Revision: https://reviews.llvm.org/D25593 llvm-svn: 285101
2016-10-26 03:43:44 +08:00
Update revision number in CHANGELOG.TXT llvm-svn: 285102
2016-10-26 03:44:38 +08:00
* r285101 - Add -fvisibility-inlines-hidden when building libc++.
[libcxx] Build with -fvisibility-inlines-hidden -- Remove 20 inline definitions from the dylib Summary: This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib. On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them. Also could a FreeBSD maintainer comment on the ABI compatibility of this patch? Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim Subscribers: beanz, mgorny, cfe-commits, modocache Differential Revision: https://reviews.llvm.org/D25593 llvm-svn: 285101
2016-10-26 03:43:44 +08:00
Although this change removes symbols, it should still be non-ABI breaking
since all of the definitions removed are inline functions. For this reason
removing these symbols is safe because every "linkage unit" which uses these
functions will contain their own definition.
x86_64-linux-gnu
----------------
SYMBOL REMOVED: _ZNSt12bad_any_castD0Ev
SYMBOL REMOVED: _ZNSt12experimental15fundamentals_v112bad_any_castD0Ev
SYMBOL REMOVED: _ZNSt3__114__codecvt_utf8IDiED0Ev
SYMBOL REMOVED: _ZNSt3__114__codecvt_utf8IDsED0Ev
SYMBOL REMOVED: _ZNSt3__114__codecvt_utf8IwED0Ev
SYMBOL REMOVED: _ZNSt3__115__codecvt_utf16IDiLb0EED0Ev
SYMBOL REMOVED: _ZNSt3__115__codecvt_utf16IDiLb1EED0Ev
SYMBOL REMOVED: _ZNSt3__115__codecvt_utf16IDsLb0EED0Ev
SYMBOL REMOVED: _ZNSt3__115__codecvt_utf16IDsLb1EED0Ev
SYMBOL REMOVED: _ZNSt3__115__codecvt_utf16IwLb0EED0Ev
SYMBOL REMOVED: _ZNSt3__115__codecvt_utf16IwLb1EED0Ev
SYMBOL REMOVED: _ZNSt3__117__assoc_sub_stateD0Ev
SYMBOL REMOVED: _ZNSt3__117__assoc_sub_stateD2Ev
SYMBOL REMOVED: _ZNSt3__117__libcpp_sscanf_lEPKcP15__locale_structS1_z
SYMBOL REMOVED: _ZNSt3__119__libcpp_asprintf_lEPPcP15__locale_structPKcz
SYMBOL REMOVED: _ZNSt3__119__libcpp_snprintf_lEPcmP15__locale_structPKcz
SYMBOL REMOVED: _ZNSt3__120__codecvt_utf8_utf16IDiED0Ev
SYMBOL REMOVED: _ZNSt3__120__codecvt_utf8_utf16IDsED0Ev
SYMBOL REMOVED: _ZNSt3__120__codecvt_utf8_utf16IwED0Ev
x86_64-apple-darwin16.0
-----------------------
No Changes - inline symbols are already hidden
Correct ABI changelog revision number llvm-svn: 284207
2016-10-14 14:47:37 +08:00
* r284206 - Implement C++17 aligned allocation in <new>
Implement P0035R4 -- Add C++17 aligned allocation functions Summary: This patch implements the library side of P0035R4. The implementation is thanks to @rsmith. In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects. Reviewers: mclow.lists, rsmith Subscribers: rsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D25591 llvm-svn: 284206
2016-10-14 14:46:30 +08:00
x86_64-linux-gnu
----------------
Symbol added: posix_memalign@GLIBC_2.2.5
Symbol added: _ZdaPvSt11align_val_t
Symbol added: _ZdlPvSt11align_val_t
Symbol added: _ZnamSt11align_val_t
Symbol added: _ZdaPvmSt11align_val_t
Symbol added: _ZdlPvmSt11align_val_t
Symbol added: _ZdlPvSt11align_val_tRKSt9nothrow_t
Symbol added: _ZnwmSt11align_val_tRKSt9nothrow_t
Symbol added: _ZnamSt11align_val_tRKSt9nothrow_t
Symbol added: _ZdaPvSt11align_val_tRKSt9nothrow_t
Symbol added: _ZnwmSt11align_val_t
Add ABI Changelog and current symbol list for Linux llvm-svn: 284185
2016-10-14 10:27:44 +08:00
* r283980 - Implement C++17 <optional>
x86_64-linux-gnu
----------------
Symbol added: _ZTISt19bad_optional_access
Symbol added: _ZNSt19bad_optional_accessD0Ev
Symbol added: _ZNSt19bad_optional_accessD1Ev
Symbol added: _ZNSt19bad_optional_accessD2Ev
Symbol added: _ZTVSt19bad_optional_access
Symbol added: _ZTSSt19bad_optional_access
Add ABI changelog entry for <any> llvm-svn: 284199
2016-10-14 13:10:06 +08:00
* r278310 - Implement C++17 <any>
x86_64-linux-gnu
----------------
Symbol added: _ZNKSt12bad_any_cast4whatEv
Symbol added: _ZNSt12bad_any_castD0Ev
Symbol added: _ZTISt12bad_any_cast
Symbol added: _ZTSSt12bad_any_cast
Symbol added: _ZTVSt12bad_any_cast
Remove more basic_string member function templates from the dylib exports llvm-svn: 295398
2017-02-17 09:53:16 +08:00
update revision in CHANGELOG.TXT and fix python error llvm-svn: 295399
2017-02-17 09:56:57 +08:00
* r295398 - Remove basic_string::insert and basic_string::replace template methods
which should be inline.
Remove more basic_string member function templates from the dylib exports llvm-svn: 295398
2017-02-17 09:53:16 +08:00
These functions should never have had visible definitions in the dylib but
since they were previously not specified with 'inline' they accidentally
got emitted. This change is non-ABI breaking because every "linkage unit"
must contain its own definition.
x86_64-linux-gnu
----------------
SYMBOL REMOVED: _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6insertIPKcEENS_9enable_ifIXaasr21__is_forward_iteratorIT_EE5valuesr38__libcpp_string_gets_noexcept_iteratorISA_EE5valueENS_11__wrap_iterIPcEEE4typeENSB_IS8_EESA_SA_
SYMBOL REMOVED: _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE7replaceIPKcEENS_9enable_ifIXsr19__is_input_iteratorIT_EE5valueERS5_E4typeENS_11__wrap_iterIS8_EESF_SA_SA_
SYMBOL REMOVED: _ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6insertIPKwEENS_9enable_ifIXaasr21__is_forward_iteratorIT_EE5valuesr38__libcpp_string_gets_noexcept_iteratorISA_EE5valueENS_11__wrap_iterIPwEEE4typeENSB_IS8_EESA_SA_
SYMBOL REMOVED: _ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE7replaceIPKwEENS_9enable_ifIXsr19__is_input_iteratorIT_EE5valueERS5_E4typeENS_11__wrap_iterIS8_EESF_SA_SA_