I need a test that only runs in a reasonable amount of time on systems
that have sparse files. The broadest class of systems that support
sparse files are linux systems. So restricting my test to linux systems
should suffice. This change adds the system-linux feature to llvm-lit so
that it can be required.
Differential Revision: https://reviews.llvm.org/D39482
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317055 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r315697 and my ill-fated attempts to fix it on Windows.
I'll try again when I get access to a Windows machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315793 91177308-0d34-0410-b5e6-96231b3b80d8
"No such file or directory: C:\\...\\tests\\Output\\shared-output.py.tmp/Output/Shared/SHARED.tmp"
And yet other forward-slashes don't seem to be causing the same
problem. I'll see if I can get ahold of a Windows machine to poke at
this directly later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315792 91177308-0d34-0410-b5e6-96231b3b80d8
I don't have access to a Windows machine at the moment, so if this
doesn't fix it I'll just revert for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315782 91177308-0d34-0410-b5e6-96231b3b80d8
I didn't think about '%{inputs}' having the same problem. This one
should be a fully Windows path name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315779 91177308-0d34-0410-b5e6-96231b3b80d8
This refers to a temporary path that can be shared across all tests,
identified by a particular label. This can be used for things like
caches.
At the moment, the character set for the LABEL is limited to C
identifier characters, plus '-', '+', '=', and '.'. This is the same
set of characters currently allowed in REQUIRES clause identifiers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315697 91177308-0d34-0410-b5e6-96231b3b80d8
This paves the way for other projects which might /use/ clang or
lld but not necessarily need to the full set of functionality
available to clang and lld tests to be able to have a basic set
of substitutions that allow a project to run the clang or lld
executables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315627 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315085 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
normpath() was being called on an empty string and appended to
the environment variable in the case where the environment variable
was unset. This led to ":." being appended to the path, since
normpath() of an empty string is '.', presumably to represent cwd.
Reviewers: zturner, sqlbyme, modocache
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38542
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314915 91177308-0d34-0410-b5e6-96231b3b80d8
Fix llvm_tools_dir attribute access not to fail when the variable is not
present. This directory is not really necessary to run lit tests,
and the code already accounts for it being None.
The reference was added in r313407, and it breaks the stand-alone lit
package in Gentoo.
Differential Revision: https://reviews.llvm.org/D38442
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314620 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Also disables leak checking on lto tests, due to many leaks reported
in the system's ld64.
Reviewers: kcc, pcc, bogner, kubamracek
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D37781
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314535 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313928 91177308-0d34-0410-b5e6-96231b3b80d8
This is breaking several bots. I have enough information to
investigate, so I'm reverting to green until I get it figured
out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313922 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313919 91177308-0d34-0410-b5e6-96231b3b80d8
This has gone back and forth, but it seems this is necessary
after all. realpath is not sufficient because if you have a
file named 'C:\foo.txt', then both realpath('c:\foo.txt') and
realpath(C:\foo.txt') return the string that was passed to them
exactly as is, meaning the case of the drive-letter won't match.
The problem before was not that we were normalizing the case of
items going into the config map, but rather that we were
normalizing the case of something we needed to print. The value
that is used to key on the config map should never be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313918 91177308-0d34-0410-b5e6-96231b3b80d8
This makes all paths lowercase on Windows, which seemed like a
good idea at the time, but it means that tests can't properly
use FileCheck to match expected path names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313889 91177308-0d34-0410-b5e6-96231b3b80d8
Config map is not exposed through the command line, so testing this
is somewhat tricky. But basically we need a test that if a custom
driver builds a config map and passes it to main, it gets respected.
A config map allows config files in the source tree to be mapped
to alternate config files in the build tree. This particular test
works by having two config files in separate directories, and
setting up a config map to have that redirects A/lit.site.cfg
to B/altconfig. Then, we print a message in A/lit.site.cfg
and B/altconfig and check that we do see the output from B
but don't see the output from A. Additionally we test that
the test suite specified by A's config map is properly discovered.
Differential Revision: https://reviews.llvm.org/D38105
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313887 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This appears to break some bots, when getToolsPath fails to find some or
all of the tools (for example, an incomplete GnuWin32 installation).
Reviewers: zturner, modocache
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D38115
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313854 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313849 91177308-0d34-0410-b5e6-96231b3b80d8
The problems on the bots appear to be resolved and this was
determined to not be the culprit. Removing this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313807 91177308-0d34-0410-b5e6-96231b3b80d8
Bug pointed out by EricWF. This would construct a path where
items would be added in the wrong order, potentially leading
to using the wrong tools for testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313765 91177308-0d34-0410-b5e6-96231b3b80d8
Many svn-based buildbots seem to be getting stuck continually
in tree conflicts due to the output of pyc files. I'm disabling
these as a temporary measure in an attempt to get everything
stable again.
I'll try to remove this code once I understand the problem
better.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313698 91177308-0d34-0410-b5e6-96231b3b80d8
Since the path a user specifies to the llvm-lit script might be
different than the source tree they built from (since they could
be behind different symlinks), we need to use realpath to make
sure that path comparisons work as expected.
Even better would be to use a custom dictionary comparison with
actual file equivalence comparison semantics, but this is the
least friction to unbreak things for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313594 91177308-0d34-0410-b5e6-96231b3b80d8
NFC intended here, this only updates clang and lld's lit configs
to use some helper functionality in the lit.llvm submodule.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313579 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't make sense to me why these bots are failing as the
traceback does not agree with the source code. It's possible
something is stale or there is some other mysterious error,
but in any case hopefully this fixes it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313469 91177308-0d34-0410-b5e6-96231b3b80d8
There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313467 91177308-0d34-0410-b5e6-96231b3b80d8
A few tests were manually constructing a LitConfig object, since
I added a new argument to it this was triggering some failures
I didn't detect. `ninja check-lit` passes now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313461 91177308-0d34-0410-b5e6-96231b3b80d8
This is helpful for debugging test failures since it removes
the multiprocessing pool from the picture. This will obviously
slow down the test suite by a few orders of magnitude, so it
should only be used for debugging specific failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313460 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like this is going to be non-trivial to get working
in both Py2 and Py3, so for now I'm reverting until I have time
to fully test it under Python 3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313429 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted alongside the revert of the lit/llvm-lit refactor,
but now that that has re-landed, I'm relanding this as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313426 91177308-0d34-0410-b5e6-96231b3b80d8
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313407 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313335 91177308-0d34-0410-b5e6-96231b3b80d8
This is breaking due to some changes I forgot to merge in, so I'm
temporarily reverting them until I can re-test that this works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313328 91177308-0d34-0410-b5e6-96231b3b80d8
To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functionality such as setting up paths, adding features that are
useful across all projects, and other utility-type functions.
For now this only updates llvm's suite to use this new library,
but subsequent patches will update other projects.
Differential Revision: https://reviews.llvm.org/D37778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313325 91177308-0d34-0410-b5e6-96231b3b80d8
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313270 91177308-0d34-0410-b5e6-96231b3b80d8
Use os.path.normpath instead of realpath to collapse '..' and '.' path
components. Use realpath when caching search results about a path for
good measure.
I considered rigging up a test involving symlinks for this, but I doubt
I can check a symlink into SVN. The test would have to conditionally
create a symlink at runtime if the host OS supports it. This sounds too
fragile and complicated to me to be worth it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312254 91177308-0d34-0410-b5e6-96231b3b80d8
This preserves symlinks in paths, so that someone can symlink more tests
into a larger test suite. For example, debuginfo-tests is currently
designed to be checked out into clang/test. With this change, it can be
symlinked into place instead, which works better with the monorepo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312250 91177308-0d34-0410-b5e6-96231b3b80d8
Jake Ehrlich