| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We currently have effectively 3 implementations of type_info: one for
the Microsoft ABI, one that does not assume that there's a unique copy
of each RTTI in a progran, and one that assumes a unique copy.
Those 3 implementations are entangled into the same class with nested
ifdefs, which makes it very difficult to understand. Furthermore, the
benefit of doing this is rather small since the code that is duplicated
across implementations is just a couple of trivial lines.
This patch stamps out the 3 versions of type_info explicitly to increase
readability. It also explains what's going on with short comments, because
it's far from obvious.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith
Differential Revision: https://reviews.llvm.org/D57606
llvm-svn: 352905
|
|
|
|
|
|
| |
test. Reviewed as https://reviews.llvm.org/D57391 Thanks to Andrey Maksimov for the patch
llvm-svn: 352781
|
|
|
|
|
|
|
|
|
|
|
| |
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352688
|
|
|
|
|
|
| |
This reverts commit r352654: this broke libcxx and sanitizer bots.
llvm-svn: 352658
|
|
|
|
|
|
|
|
|
|
|
| |
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352654
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building on Windows without libc++abi, this change fixes a build error of the form:
src/new.cpp(38,17): error: chosen constructor is explicit in copy-initialization
const nothrow_t nothrow = {};
include/vcruntime_new.h(53,22): note: explicit constructor declared here
explicit nothrow_t() = default;
Differential Revision: https://reviews.llvm.org/D57351
llvm-svn: 352648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes build errors on Windows without libc++abi of the form:
new(173,36): error: redeclaration of 'operator delete' cannot add 'dllexport' attribute
_LIBCPP_OVERRIDABLE_FUNC_VIS void operator delete(void* __p) _NOEXCEPT;
vcruntime_new.h(87,16): note: previous declaration is here
void __CRTDECL operator delete(
new(205,70): error: redefinition of 'operator new'
_LIBCPP_NODISCARD_AFTER_CXX17 inline _LIBCPP_INLINE_VISIBILITY void* operator new (std::size_t, void* __p) _NOEXCEPT {return __p;}
vcruntime_new.h(184,28): note: previous definition is here
inline void* __CRTDECL operator new(size_t _Size, _Writable_bytes_(_Size) void* _Where) noexcept
new(206,70): error: redefinition of 'operator new[]'
_LIBCPP_NODISCARD_AFTER_CXX17 inline _LIBCPP_INLINE_VISIBILITY void* operator new[](std::size_t, void* __p) _NOEXCEPT {return __p;}
vcruntime_new.h(199,28): note: previous definition is here
inline void* __CRTDECL operator new[](size_t _Size,
new(207,40): error: redefinition of 'operator delete'
inline _LIBCPP_INLINE_VISIBILITY void operator delete (void*, void*) _NOEXCEPT {}
vcruntime_new.h(190,27): note: previous definition is here
inline void __CRTDECL operator delete(void*, void*) noexcept
new(208,40): error: redefinition of 'operator delete[]'
inline _LIBCPP_INLINE_VISIBILITY void operator delete[](void*, void*) _NOEXCEPT {}
vcruntime_new.h(206,27): note: previous definition is here
inline void __CRTDECL operator delete[](void*, void*) noexcept
Differential Revision: https://reviews.llvm.org/D57362
llvm-svn: 352647
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exception destructors are provided by vcruntime. Fixes link errors like:
lld-link: error: duplicate symbol: "public: virtual __cdecl std::invalid_argument::~invalid_argument(void)" (??1invalid_argument@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj)
lld-link: error: duplicate symbol: "public: virtual __cdecl std::length_error::~length_error(void)" (??1length_error@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj)
lld-link: error: duplicate symbol: "public: virtual __cdecl std::out_of_range::~out_of_range(void)" (??1out_of_range@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj)
lld-link: error: duplicate symbol: "public: virtual __cdecl std::overflow_error::~overflow_error(void)" (??1overflow_error@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj)
Differential Revision: https://reviews.llvm.org/D57425
llvm-svn: 352646
|
|
|
|
|
|
|
|
|
|
|
|
| |
On my Windows system, __allocator is defined to nothing. This change fixes build errors of the below form:
In file included from algorithm:644:
functional(1492,31): error: expected member name or ';' after declaration specifiers
const _Alloc& __allocator() const { return __f_.second(); }
Differential Revision: https://reviews.llvm.org/D57355
llvm-svn: 352561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_LIBCPP_FUNC_VIS is redundant since the class is already annotated with
_LIBCPP_EXCEPTION_ABI.
Fixes this build error:
In file included from fstream:188:
filesystem(1350,3): error: attribute 'dllimport' cannot be applied to member of 'dllimport' class
_LIBCPP_FUNC_VIS
__config(674,37): note: expanded from macro '_LIBCPP_FUNC_VIS'
#define _LIBCPP_FUNC_VIS _LIBCPP_DLL_VIS
__config(666,38): note: expanded from macro '_LIBCPP_DLL_VIS'
# define _LIBCPP_DLL_VIS __declspec(dllimport)
filesystem(1313,7): note: previous attribute is here
class _LIBCPP_EXCEPTION_ABI filesystem_error : public system_error {
__config(675,37): note: expanded from macro '_LIBCPP_EXCEPTION_ABI'
#define _LIBCPP_EXCEPTION_ABI _LIBCPP_DLL_VIS
__config(666,38): note: expanded from macro '_LIBCPP_DLL_VIS'
# define _LIBCPP_DLL_VIS __declspec(dllimport)
Differential Revision: https://reviews.llvm.org/D57354
llvm-svn: 352525
|
|
|
|
|
|
|
|
|
|
|
| |
The meta-programming that attempted to form the invoke call expression
was not in a SFINAE context. This made it a hard error to provide
non-referencable types like 'void' or 'void (...) const'.
This patch fixes the error by checking the validity of the call
expression within a SFINAE context.
llvm-svn: 352522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
|
|
|
|
| |
llvm-svn: 352513
|
|
|
|
|
|
| |
deque/unordered containers as 'libc++-specific'. Thanks to Andrey Maksimov for pointing this out.
llvm-svn: 352512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable.
Differential Revision: https://reviews.llvm.org/D56702
llvm-svn: 352425
|
|
|
|
|
|
|
|
|
| |
library"
This reverts commit r352341: it broke the build on macOS which doesn't
seem to provide __libc_start_main in its C library.
llvm-svn: 352411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT,
and require the fallback to be defined explicitly
as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone
after r346888.
The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache
variable and an optional pre-definition of default value from caller
(e.g. libcxx). It included a hack to make this work by assigning
the value back and forth but it was fragile and stopped working
in libcxx.
The new logic is simpler and more transparent. Default value is
provided in a separate variable, and used only when user-specified
variable is empty (i.e. not overriden).
Differential Revision: https://reviews.llvm.org/D57282
llvm-svn: 352374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check_library_exists CMake uses a custom symbol definition. This
is a problem when checking for C library symbols because Clang
recognizes many of them as builtins, and returns the
-Wbuiltin-requires-header (or -Wincompatible-library-redeclaration)
error. When building with -Werror which is the default, this causes
the check_library_exists check fail making the build think that C
library isn't available.
To avoid this issue, we should use a symbol that isn't recognized by
Clang and wouldn't cause the same issue. __libc_start_main seems like
reasonable choice that fits the bill.
Differential Revision: https://reviews.llvm.org/D57142
llvm-svn: 352341
|
|
|
|
| |
llvm-svn: 352339
|
|
|
|
|
|
| |
Reported on the NetBSD 8 build bot.
llvm-svn: 352097
|
|
|
|
|
|
| |
tests' I had to cut back on the tests with this, because they were not C++03 friendly. Thanks to gribozavr for the patch
llvm-svn: 352087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not required to be the same
The unordered_set and unordered_multiset iterators are specified in the standard as follows:
using iterator = implementation-defined; // see [container.requirements]
using const_iterator = implementation-defined; // see [container.requirements]
using local_iterator = implementation-defined; // see [container.requirements]
using const_local_iterator = implementation-defined; // see [container.requirements]
The pairs iterator/const_iterator and local_iterator/const_local_iterator
are not required to be the same. The reasonable requirement would be that
iterator can convert to const_iterator and local_iterator can convert to
const_local_iterator. This patch weakens the check and makes the test
more portable.
Reviewed as https://reviews.llvm.org/D56493.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 352083
|
|
|
|
|
|
| |
Reported on the NetBSD 8 buildbot.
llvm-svn: 352064
|
|
|
|
| |
llvm-svn: 352007
|
|
|
|
|
|
| |
locales that aren't generally available there, similar to the other regex tests
llvm-svn: 352006
|
|
|
|
|
|
| |
Reported on the NetBSD 8 buildbot.
llvm-svn: 351995
|
|
|
|
| |
llvm-svn: 351993
|
|
|
|
|
|
|
|
|
|
|
| |
msvc_stdlib_force_include.hpp
...so the tests under test/std/utilities/any continue to
compile with MSVC's standard library.
While we're here, let's test >C++17 features when _HAS_CXX20.
llvm-svn: 351991
|
|
|
|
|
|
| |
Reported on the NetBSD 8 buildbot.
llvm-svn: 351988
|
|
|
|
|
|
| |
Add missing trailing dot.
llvm-svn: 351983
|
|
|
|
|
|
| |
output buffers correctly' which has been hanging around for a long time
llvm-svn: 351971
|
|
|
|
|
|
| |
Reported on the NetBSD 8 buildbot
llvm-svn: 351944
|
|
|
|
|
|
| |
Reported on the NetBSD 8 buildbot.
llvm-svn: 351937
|
|
|
|
|
|
| |
constructor tests. They were not testing the stuff that they said they were. Updated the tests to test what they should have been doing
llvm-svn: 351887
|
|
|
|
|
|
|
| |
Reviewed as https://reviews.llvm.org/D56503.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 351847
|
|
|
|
| |
llvm-svn: 351832
|
|
|
|
| |
llvm-svn: 351773
|
|
|
|
| |
llvm-svn: 351770
|
|
|
|
|
|
|
|
|
|
|
| |
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
|
|
|
|
|
|
|
|
|
|
| |
D56445 bumped the minimum Mac OS X version required for aligned
allocation from 10.13 to 10.14. This caused libc++ tests depending
on the old value to break.
This patch updates the XFAILs for those tests to include 10.13.
llvm-svn: 351670
|
|
|
|
|
|
|
|
|
| |
This reverts commit r351625.
That fix was incomplete. I'm reverting so I can commit a complete fix
in a single revision.
llvm-svn: 351669
|
|
|
|
| |
llvm-svn: 351667
|
|
|
|
| |
llvm-svn: 351653
|
|
|
|
| |
llvm-svn: 351650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
The buildbot start scripts hardcode the version string.
Bump it from 8 to 9.
llvm-svn: 351638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
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: 351636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
|
|
|
|
|
|
|
|
|
|
| |
D56445 bumped the minimum Mac OS X version required for aligned
allocation from 10.13 to 10.14. This caused libc++ tests depending
on the old value to break.
This patch updates the XFAILs for those tests to include 10.13.
llvm-svn: 351625
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Samuel Thibault
The GNU/Hurd system does not define an arbitrary PATH_MAX limitation, the POSIX 2001 realpath
extension can be used instead, and the size of symlinks can be determined.
Reviewed as https://reviews.llvm.org/D54677
llvm-svn: 351414
|