Now that almost all functionality of Apple's dsymutil has been
upstreamed, the open source variant can be used as a drop in
replacement. Hence we feel it's no longer necessary to have the llvm
prefix.
Differential revision: https://reviews.llvm.org/D44527
llvm-svn: 327790
These tests assumes availability of external symbols provided by the
C++ library, but those won't be available in case when the C++ library
is statically linked because lli itself doesn't need these.
This uses llvm-readobj -needed-libs to check if C++ library is linked as
shared library and exposes that information as a feature to lit.
Differential Revision: https://reviews.llvm.org/D41272
llvm-svn: 321981
Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.
This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).
It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.
Differential Revision: https://reviews.llvm.org/D40202
Fixes since the first commit:
1. Disable syntax highlighting as different versions of pygments generate
different HTML
2. Use llvm-cxxfilt from the build
llvm-svn: 319324
I have a test that I'd like to add to llvm that demands using more than
32-bits worth of address space. This test can't be run on 32-bit systems
because they don't have enough address space. The host triple should be
used to determine this instead of config.host_arch because on Debian
systems config.host_arch is not correct. This change adds the
"host-arch-is-64bit" feature to allow tests to restrict themselves to
the 64-bit case.
Differential Revision: https://reviews.llvm.org/D39465
llvm-svn: 317281
This addresses two sources of inconsistency in test configuration
files.
1. Substitution boundaries. Previously you would specify a
substitution, such as 'lli', and then additionally a set
of characters that should fail to match before and after
the tool. This was used, for example, so that matches that
are parts of full paths would not be replaced. But not all
tools did this, and those that did would often re-invent
the set of characters themselves, leading to inconsistency.
Now, every tool substitution defaults to using a sane set
of reasonable defaults and you have to explicitly opt out
of it. This actually fixed a few latent bugs that were
never being surfaced, but only on accident.
2. There was no standard way for the system to decide how to
locate a tool. Sometimes you have an explicit path, sometimes
we would search for it and build up a path ourselves, and
sometimes we would build up a full command line. Furthermore,
there was no standardized way to handle missing tools. Do we
warn, fail, ignore, etc? All of this is now encapsulated in
the ToolSubst class. You either specify an exact command to
run, or an instance of FindTool('<tool-name>') and everything
else just works. Furthermore, you can specify an action to
take if the tool cannot be resolved.
Differential Revision: https://reviews.llvm.org/D38565
llvm-svn: 315085
There were two issues, one Python 3 specific related to Unicode,
and another which is that the tool substitution for lld no longer
rejected matches where a / preceded the tool name.
llvm-svn: 313928
debuginfo-tests has need to reuse a lot of common configuration
from clang and lld, and in general it seems like all of the
projects which are tightly coupled (e.g. lld, clang, llvm, lldb,
etc) can benefit from knowing about one other. For example,
lldb needs to know various things about how to run clang in its
test suite. Since there's a lot of common substitutions and
operations that need to be shared among projects, sinking this
up into LLVM makes sense.
In addition, this patch introduces a function add_tool_substitution
which handles all the dirty intricacies of matching tool names
which was previously copied around the various config files. This
is now a simple straightforward interface which is hard to mess
up.
Differential Revision: https://reviews.llvm.org/D37944
llvm-svn: 313919
Many editors and Python-related diagnostics tools such as
debuggers break or fail in mysterious ways when python files
don't end in .py. This is especially true on Windows, but
still exists on other platforms. I don't want to be too heavy
handed in changing everything across the board, but I do want
to at least *allow* lit configs to have .py extensions. This
patch makes the discovery process first look for a config file
with a .py extension, and if one is not found, then looks for
a config file using the old method. So for existing users, there
should be no functional change.
Differential Revision: https://reviews.llvm.org/D37838
llvm-svn: 313849
Jonas Devlieghere