| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 296922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 296919
|
|
|
|
|
|
| |
Was hitting: "error: scalar initializer cannot be empty"
llvm-svn: 296889
|
|
|
|
| |
llvm-svn: 296854
|
|
|
|
| |
llvm-svn: 296851
|
|
|
|
| |
llvm-svn: 296840
|
|
|
|
| |
llvm-svn: 296831
|
|
|
|
|
|
| |
when ran in c++11 mode 32 bits
llvm-svn: 296830
|
|
|
|
|
|
| |
definitions
llvm-svn: 296822
|
|
|
|
| |
llvm-svn: 296813
|
|
|
|
| |
llvm-svn: 296805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
them.
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
llvm-svn: 296802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 296732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 296727
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 296725
|
|
|
|
|
|
|
|
|
|
|
| |
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...
llvm-svn: 296724
|
|
|
|
| |
llvm-svn: 296716
|
|
|
|
|
|
|
|
| |
This tests is failing in XCode 7.0. But Xcode 7.3 that shipped
an updated clang has this test passing. This is fixing green dragon
which runs this configuration.
llvm-svn: 296712
|
|
|
|
|
|
|
|
|
| |
These tests are failing in XCode 8.0, 8.1, and 8.2, but not in Xcode
8.3. Annoyingly the version numbering for clang does not follow Xcode
and is bumped to 8.1 only in Xcode 8.3. So Xfailing apple-clang-8.0
should catch all cases here.
llvm-svn: 296704
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the CMake configuration so that it always
generates the test/lit.site.cfg file, even when testing is disabled.
This allows users to test libc++ without requiring them to have
a full LLVM checkout on their machine.
llvm-svn: 296685
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30278
llvm-svn: 296573
|
|
|
|
| |
llvm-svn: 296571
|
|
|
|
| |
llvm-svn: 296568
|
|
|
|
|
|
|
|
|
| |
This patch adds a static assertion that the specified hash meets
the requirements of an enabled hash, and it ensures that the static
assertion is evaluated before __compressed_pair is instantiated.
That way the static assertion diagnostic is emitted first.
llvm-svn: 296565
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes llvm.org/PR32097 by using the __is_abstract
builtin type-trait instead of the previous library-only implementation.
All supported compilers provide this trait. I've tested as far
back as Clang 3.2, GCC 4.6 and MSVC trunk.
llvm-svn: 296561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`ConstexprTestTypes::NoCtors` is an aggregate type (and consequently a literal type) in C++17,
but not in C++14 since it has a base class. This patch updates the comment to accurately describe the reason for the XFAIL.
Reviewers: EricWF
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D30481
llvm-svn: 296558
|
|
|
|
|
|
|
|
| |
The clang assertion causing these tests failing with sanitizer is fixed
in r295794. All the bots running libcxx tests should be upgraded and
running the compiler with the fix.
llvm-svn: 296385
|
|
|
|
|
|
| |
Add the missing check in the __config header.
llvm-svn: 296351
|
|
|
|
| |
llvm-svn: 296346
|
|
|
|
| |
llvm-svn: 296338
|
|
|
|
|
|
|
|
|
| |
This reverts SVN r295329. Although `__libcpp_thread_sleep_for` should
be alertable, the implementation causes a large regression in the test
suite. Add a FIXME item there for now to get the test suite in a better
state before attempting to fix that behaviour.
llvm-svn: 295561
|
|
|
|
|
|
|
| |
When running under clang-cl mode, we do not define `__GNUC__`, resulting
in the test failing.
llvm-svn: 295560
|
|
|
|
|
|
|
|
| |
When building with MSVCRT, we need to manually provide the type
promoting overloads to allow the correct type deduced invocation for
signbit(Int) and fpclassify(int).
llvm-svn: 295559
|
|
|
|
|
|
|
| |
On certain targets, enumerations may be smaller than an `unsigned long`.
Use an explicitly sized enumeration.
llvm-svn: 295558
|
|
|
|
|
|
|
|
|
| |
The path would previously get an extra leading space as the arguments
would be parsed when generating the final command to run. Pretokenise
the arguments to permit proper quoting of the paths. This avoids a
number of ignoring non-existent path warnings from clang.
llvm-svn: 295511
|
|
|
|
|
|
| |
MAJOR was misspelt as NAJOR. Fix the spelling.
llvm-svn: 295510
|
|
|
|
|
|
|
| |
MSVCRT 14+ supports the C99 math routines that we need. Use them
accordingly.
llvm-svn: 295509
|
|
|
|
| |
llvm-svn: 295434
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC 7.0.1 started warning that __attribute__((__strong__)) is depricated.
This patch switches to using inline namespace with GCC instead. I believe
this wasn't done originally in order to support older GCC versions w/o
support for inline namespaces, or because earlier versions of GCC warned
users that the STL was using an inline namespace (even though it shouldn't affect users).
However I believe all of the above problems are gone for GCC 4.9 and greater.
Therefore switching to using inline namespaces instead of using __strong__
is the most correct behavior.
llvm-svn: 295428
|
|
|
|
| |
llvm-svn: 295423
|
|
|
|
| |
llvm-svn: 295422
|
|
|
|
| |
llvm-svn: 295417
|
|
|
|
|
|
| |
_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES
llvm-svn: 295407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements [P0003R5](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html) which removes exception specifications from C++17.
The only changes to the library are removing `set_unexpected`, `get_unexpected`, `unexpected`, and `unexpected_handler`. These functions can be re-enabled in C++17 using `_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS`.
@mclow.lists what do you think about removing stuff is this way?
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D28172
llvm-svn: 295406
|
|
|
|
|
|
| |
this time.
llvm-svn: 295403
|
|
|
|
| |
llvm-svn: 295399
|
|
|
|
| |
llvm-svn: 295398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter types.
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
|