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
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
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
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
...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
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
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
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
Summary:
FreeBSD ships a very old and deprecated ABI for std::pair where the copy and move constructors are not allowed to be trivial. D25389 change how this was implemented by introducing a non-trivial base class. This patch, introduced in October 2016, introduced an ABI bug that caused nested `std::pair` instantiations to have padding. For example:
```
using PairT = std::pair< std::pair<char, char>, char >;
static_assert(offsetof(PairT, first) == 0, "First member should exist at offset zero"); // Fails on FreeBSD!
```
The bug occurs because the base class for the first element (the nested pair) cannot be put at offset zero because the top-level pair already has the same base class laid out there.
This patch fixes that ABI bug by templating the dummy base class on the same parameters as the pair.
Technically this fix is an ABI break for users who depend on the "broken" ABI introduced in 2016. I'm putting this up for review so that the FreeBSD maintainers can sign off on fixing the ABI by breaking the ABI.
Another option, since we have to "break" the ABI to fix it, would be to move FreeBSD off the deprecated non-trivial pair ABI instead.
Also see:
* https://llvm.org/PR40230
* https://reviews.llvm.org/D21329
Reviewers: rsmith, dim, emaste
Reviewed By: rsmith
Subscribers: mclow.lists, krytarowski, christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56357
llvm-svn: 351290
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: ldionne, EricWF
Subscribers: jyknight, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 351289
Summary:
This patch implements all the feature test macros libc++ currently supports, as specified by the standard or cppreference prior to C++2a.
The tests and `<version>` header are generated using a script. The script contains a table of each feature test macro, the headers it should be accessible from, and its values of each dialect of C++.
When a new feature test macro is added or needed, the table should be updated and the script re-run.
Reviewers: mclow.lists, jfb, serge-sans-paille
Reviewed By: mclow.lists
Subscribers: arphaman, jfb, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56750
llvm-svn: 351286
Thomas Anderson