Summary:
The operators simply print the underlying value or "None".
The trickier part of this patch is making sure the streaming operators
work even in unit tests (which was my primary motivation, though I can
also see them being useful elsewhere). Since the stream operator was a
template, implicit conversions did not kick in, and our gtest glue code
was explicitly introducing an implicit conversion to make sure other
implicit conversions do not kick in :P. I resolve that by specializing
llvm_gtest::StreamSwitch for llvm:Optional<T>.
Reviewers: sammccall, dblaikie
Reviewed By: sammccall
Subscribers: mgorny, dexonsmith, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D56795
llvm-svn: 351548
The check-hwasan build files assert that current_os == "linux" || current_os ==
"android", so pull it in only there.
ar is unused on mac, so don't set it in the stage2 toolchain. (It'd be nicer to
use llvm-libtool on mac instead of host libtool, but llvm-libtool doesn't seem
to understand the -no_warning_for_no_symbols flag.)
Differential Revision: https://reviews.llvm.org/D56898
llvm-svn: 351519
llvm/tools sets LLVM_TOOL_LTO_BUILD to Off if LLVM_ENABLE_PIC=OFF, but that's
not visible in llvm/test.
r289662 added the llvm_tool_lto_build lit parameter, there the intent was to
use it with an explicit -DLLVM_TOOL_LTO_BUILD=OFF, which is visible globally.
On the review for that (D27739), a mild preference was expressed for using a
lit parameter over checking the existence of libLTO.dylib. Since that works
with the LLVM_ENABLE_PIC=OFF case too and since it matches what we do for the
gold plugin, switch to that approach.
Differential Revision: https://reviews.llvm.org/D56805
llvm-svn: 351515
This broke the build, ending up with too long command-lines when invoking gen-mscv-exports.py.
> As it says in the subject, should have gone long enough now that this
> should be safe. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 351329
As it says in the subject, should have gone long enough now that this
should be safe. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 351324
The Android sanitizer tests are currently some of the most difficult
to run correctly, requiring at least 3 build directories which have
to be configured in just the right way and built in the correct order
(see e.g. [1] and the functions that it calls).
This patch adds a check-hwasan target which greatly simplifies running
the hwasan tests for gn users, taking advantage of its support for
multiple toolchains. With this the tests can be run simply by setting
an NDK path and running "ninja check-hwasan" with a compatible Android
device connected. The Linux/x86_64 and Android/aarch64 targets are
tested in parallel.
[1] https://github.com/llvm/llvm-zorg/blob/master/zorg/buildbot/builders/sanitizers/buildbot_android.sh
Differential Revision: https://reviews.llvm.org/D56713
llvm-svn: 351277
The path to the resource directory will end up being used in several
more places once the support for running check-hwasan lands. This
moves the definition to a central location so that it can be used
from those places.
Differential Revision: https://reviews.llvm.org/D56700
llvm-svn: 351255
While here, add a use_lld flag and default it to true when using
clang on non-mac.
Differential Revision: https://reviews.llvm.org/D56710
llvm-svn: 351248
This makes e.g. ToolChain::isCrossCompiling() in
clang/lib/Driver/ToolChain.cpp return the correct result
if the compiler was cross-compiled. This change also affects
llvm_default_target_triple, so cross-compiled compilers default to
targeting the cross-compilation target, which makes more sense than
the host that the compiler was compiled on.
This change will also be necessary in order for the correct triples
to appear in generated lit files for non-native targets.
Differential Revision: https://reviews.llvm.org/D56696
llvm-svn: 351168
Add an asm tool (will be required for building sanitizer_common on
x64) and set a soname for DSOs so that anything that links against
them gets the correct DT_NEEDED.
Differential Revision: https://reviews.llvm.org/D56705
llvm-svn: 351167
Some of the sanitizer runtime code needs to be built with RTTI;
this allows that code to opt in to RTTI.
Differential Revision: https://reviews.llvm.org/D56627
llvm-svn: 351155
This is needed because otherwise if source dir is at location whose path
contains non-ASCII character then python will complain about
SyntaxError.
SyntaxError: Non-ASCII character '\xc4' in file
/home/D?vis/libc++/src/build/bin/llvm-lit on line 16, but no encoding
declared; see http://python.org/dev/peps/pep-0263/ for details
Patch by davispuh
Differential Revision: https://reviews.llvm.org/D50201
llvm-svn: 351113
Since people weren't enthused about moving the .gn file to the toplevel in
D56419, here's a script to make gn at least somewhat more pleasant to invoke
(useful for gn clean, gn args --list, gn desc, etc).
Differential Revision: https://reviews.llvm.org/D56565
llvm-svn: 351064
Summary:
While the backend code of FileCheck relies on definition of variable
from the command-line to have an equal sign '=' and a variable name
before that, the frontend does not actually enforce it. This leads to
FileCheck crashing when invoked with invalid syntax for the -D option.
This patch adds the missing validation in the frontend. It also makes
the -D option an AlwaysPrefix option to be able to detect -D=FOO as
being a define without variable and -D as missing its value.
Copyright:
- Linaro (changes in version 2 of revision D55940)
- GraphCore (changes in later versions)
Reviewers: jdenny
Subscribers: JonChesterfield, hiraditya, kristina, probinson,
llvm-commits
Differential Revision: https://reviews.llvm.org/D55940
llvm-svn: 351039
This shortcut mechanism for creating types was added 10 years ago, but
has seen almost no uptake since then, neither internally nor in
external projects.
The very small number of characters saved by using it does not seem
worth the mental overhead of an additional type-creation API, so,
delete it.
Differential Revision: https://reviews.llvm.org/D56573
llvm-svn: 351020
I didn't break all that much during upstreaming, just needs two small fixes:
- fix spelling of MCJITTests.def file
- make libLTO a shared_library to put it in bin/ on Windows where it is in the
CMake build too
Differential Revision: https://reviews.llvm.org/D56630
llvm-svn: 351004
This makes it possible to build llvm-symbolizer for Android, which
is one of the prerequisites for running the sanitizer tests on Android.
Differential Revision: https://reviews.llvm.org/D56577
llvm-svn: 350979
Also change the toolchain description to use current_os instead of
host_os so that the template can be used for cross builds, and add
a current_os to the win toolchain to match the unix toolchain.
Differential Revision: https://reviews.llvm.org/D56576
llvm-svn: 350977
This makes the generated files go to the right place when using a non-default toolchain.
Differential Revision: https://reviews.llvm.org/D56427
llvm-svn: 350963
Most significantly, this makes bin/llvm-lit executable so that it
can be run in the usual way.
Differential Revision: https://reviews.llvm.org/D56423
llvm-svn: 350688
