The latest clang in our tree now passes the below four tests, so
remove their XFAIL:
libc++ :: std/strings/string.view/string_view.literals/literal.pass.cpp
libc++ :: std/strings/string.view/string_view.literals/literal1.pass.cpp
libc++ :: std/strings/string.view/string_view.literals/literal2.pass.cpp
libc++ :: std/strings/string.view/string_view.literals/literal3.pass.cpp
Bug: 36400049
Test: ./run_tests.py
Change-Id: I309d1eed2a04ab13165167ab2c0b3a8334014cbd
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 36426473
Bug: 36079834
Test: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Test: attempt to compile with BOARD_VNDK_VERSION := current
Change-Id: I5aa9e3463c53a2c13110d6fffb61a2bbc09892f2
Clang doesn't produce gcov compatible coverage files. This
causes lcov to break because it uses gcov by default. This
patch switches lcov to use llvm-cov as the gcov-tool.
Unfortunatly llvm-cov doesn't provide a gcov like interface by
default so it won't work with lcov. However `llvm-cov gcov` does.
For this reason we generate 'llvm-cov-wrapper' script that always
passes the gcov flag.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@297553 91177308-0d34-0410-b5e6-96231b3b80d8
basic_string::replace() has the below line
__sz += __n2 - __n1;
which fails overflow checks if __n1 > __n2, as the negative result
from the subtraction then overflows the original __sz when added to
it.
This behavior is valid as unsigned integer overflow is defined to wrap
around the maximum value and that produces the correct final value for
__sz. Therefore, we disable this check on this function.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@297355 91177308-0d34-0410-b5e6-96231b3b80d8
Put proper guards around _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS.
No functional change on non-Windows. Avoids incorrect macro redefinition
on Windows.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@297330 91177308-0d34-0410-b5e6-96231b3b80d8
r296565 attempted to add better diagnostics when an unordered container
is instantiated with a hash that doesn't meet the Hash requirements.
However I mistakenly checked the wrong set of requirements. Specifically
it checked if the hash met the requirements for specializations of
std::hash. However these requirements are stricter than the generic
Hash requirements.
This patch fixes the assertions to only check the Hash requirements.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296919 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them.
This patch adds the CMake option `-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS` which defaults no `ON` unless `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON` is specified.
Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, mgorny, rmaprath
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30516
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296802 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some
of their members exported, otherwise we have a lot of link errors when
linking against a libc++ built with hidden visibility. This also makes
_LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it
already exports members.
With this change made, any template methods of a class marked
_LIBCPP_TYPE_VIS will also get default visibility when instantiatied,
which is not desirable for clients of libc++ headers who wish to control
their visibility; this is the same issue as PR30642. Annotate all
problematic methods with an explicit visibility specifier to avoid this.
The problematic methods were found by running bad-visibility-finder [1]
against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The
small methods were marked for inlining; the larger ones hidden.
[1] https://github.com/smeenai/bad-visibility-finder
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25208
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296732 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296731 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296729 91177308-0d34-0410-b5e6-96231b3b80d8
The test is passing with c++11 and c++14 but not c++1z on this
particular version of the compiler. Try to use lit boolean condition
to satisfy this constaint.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296725 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r296712. It broke our bot.
It turns out that the test is passing with c++11 and c++14 but
not c++1z on this particular version of the compiler. Since one
job is defaulting to c++1z and the other is testing all config I'm
not sure how to fix this...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296724 91177308-0d34-0410-b5e6-96231b3b80d8
