bcm5719-llvm/libcxx/include/initializer_list, branch meklort-10.0.1Project Ortega BCM5719 LLVMhttps://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.12019-05-29T16:01:36+00:00[NFC][libcxx] Remove trailing whitespace2019-05-29T16:01:36+00:00Louis Dionneldionne@apple.com2019-05-29T16:01:36+00:00urn:sha1:a2a1ec27d0e799725cdd41f8456deb9a49433e2d
It's incredibly annoying when trying to create diffs
llvm-svn: 361981
Update more file headers across all of the LLVM projects in the monorepo2019-01-19T10:56:40+00:00Chandler Carruthchandlerc@gmail.com2019-01-19T10:56:40+00:00urn:sha1:57b08b0944046a6a57ee9b7b479181f548a5b9b4
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
[libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY2018-07-11T23:14:33+00:00Louis Dionneldionne@apple.com2018-07-11T23:14:33+00:00urn:sha1:dc7200b486b6c5b5229abcee97c160145cc3d955
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
Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"2018-07-05T18:41:50+00:00Louis Dionneldionne@apple.com2018-07-05T18:41:50+00:00urn:sha1:195a499d638db5157a64c9c816b76154096ecd52
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
[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY2018-07-05T16:49:38+00:00Louis Dionneldionne@apple.com2018-07-05T16:49:38+00:00urn:sha1:4a8f3f994821e752319b9c76ed772ec0c40b5d03
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
Cleanup _LIBCPP_HAS_NO_<c++11-feature> macros for std::initializer_list2017-04-18T23:09:36+00:00Eric Fiseliereric@efcs.ca2017-04-18T23:09:36+00:00urn:sha1:94b2bde631ae32ac733e2a8ca920e6a8bfa99150
llvm-svn: 300623
[NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS2017-01-04T23:56:00+00:00Eric Fiseliereric@efcs.ca2017-01-04T23:56:00+00:00urn:sha1:e2f2d1edef9fda1c7533850cdcbeccf8083a677a
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
Apply constexpr to initializer_list for c++1y.2013-08-26T20:11:32+00:00Howard Hinnanthhinnant@apple.com2013-08-26T20:11:32+00:00urn:sha1:93288117a546ee31a4a9ff91ce48b1038cc21075
llvm-svn: 189271
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.2013-08-12T18:38:34+00:00Howard Hinnanthhinnant@apple.com2013-08-12T18:38:34+00:00urn:sha1:f0544c2086a1a592e294f24d62973ce732af33da
llvm-svn: 188192
No functionality change at this time. I've split _LIBCPP_VISIBLE up into two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute.2013-03-06T23:30:19+00:00Howard Hinnanthhinnant@apple.com2013-03-06T23:30:19+00:00urn:sha1:6e41256f6803ae236c51748c1b3472443b14c639
llvm-svn: 176593