There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
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
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
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
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
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
Louis Dionne