Add Support for Creating and Deleting Unicode Files and Directories in Lit

This enables lit to work with unicode file names via mkdir, rm, and redirection.
Lit still uses utf-8 internally, but conve

Add Support for Creating and Deleting Unicode Files and Directories in Lit

This enables lit to work with unicode file names via mkdir, rm, and redirection.
Lit still uses utf-8 internally, but converts to utf-16 on Windows, or just utf-8
bytes on everything else.

Committed on behalf of Jason Mittertreiner
Differential Revision: https://reviews.llvm.org/D56754

llvm-svn: 355122

show more ...

[lit][NFC] Cleanup lit worker process handling

Move code that is executed on worker process to separate file. This
makes the use of the pickled arguments stored in global variables in the
worker a b

[lit][NFC] Cleanup lit worker process handling

Move code that is executed on worker process to separate file. This
makes the use of the pickled arguments stored in global variables in the
worker a bit clearer. (Still not pretty though.)

Extract handling of parallelism groups to it's own function.

Use BoundedSemaphore instead of Semaphore. BoundedSemaphore raises for
unmatched release() calls.

Cleanup imports.

Differential Revision: https://reviews.llvm.org/D58196

llvm-svn: 354187

show more ...

lit: Let lit.util.which() return a normcase()ed path

LLVMConfig.with_environment() uses os.path.normcase(os.path.normpath(x)) to
normalize temporary env vars. LLVMConfig.use_clang() uses with_enviro

lit: Let lit.util.which() return a normcase()ed path

LLVMConfig.with_environment() uses os.path.normcase(os.path.normpath(x)) to
normalize temporary env vars. LLVMConfig.use_clang() uses with_environment() to
temporarily set PATH and then look for clang there. This means that on Windows,
clang will be run with a path like c:\foo\bin\clang.EXE (with a lower-case
"C:").

lit.util.which() used to not do this, which means the executables added in
clang/test/lit.cfg.py (e.g. c-index-test) were run with a path like
C:\foo\bin\c-index-test.EXE (because both CMake and GN happen to write
clang_tools_dir with an upper-case C to lit.site.cfg.py).

clang/test/Index/pch-from-libclang.c requires that both c-index-test and clang
use _exactly_ the same resource dir path (same case and everything), because a
hash of the resource directory is used as module cache path.

This patch is necessary but not sufficient to make pch-from-libclang.c pass on
Windows.

Differential Revision: https://reviews.llvm.org/D57343

llvm-svn: 352704

show more ...

Python compat - print statement

Make sure all print statements are compatible with Python 2 and Python3 using
the `from __future__ import print_function` statement.

Differential Revision: https://r

Python compat - print statement

Make sure all print statements are compatible with Python 2 and Python3 using
the `from __future__ import print_function` statement.

Differential Revision: https://reviews.llvm.org/D56249

llvm-svn: 350307

show more ...

Mostly revert r330672.

The test is apparently needed e.g. for check-cfi on Windows where we get
'C:/b/slave/sanitizer-windows/build/./bin/clang.exe': command not found
without it. Try to fix the

Mostly revert r330672.

The test is apparently needed e.g. for check-cfi on Windows where we get
'C:/b/slave/sanitizer-windows/build/./bin/clang.exe': command not found
without it. Try to fix the problem that was fixed by r330672 by also checking
for isabs() instead.

llvm-svn: 330673

show more ...

Remove code that's almost always dead, and harmful if not.

lit's util.which() would check if the passed-in path existed directly,
and if so return it as-is. This is never the case when running llvm

Remove code that's almost always dead, and harmful if not.

lit's util.which() would check if the passed-in path existed directly,
and if so return it as-is. This is never the case when running llvm's, clang's,
or lld's tests normally. But when running `./llvm-lit path/to/clang/test`
with a cwd of llvm-build/bin, this if would detect that clang exists at path
'clang' and return 'clang' as the discovered clang binary -- and then lit would
use the " clang " -> "*** Do not use 'clang' in tests, use '%clang'. ***"
substitution to replace that with a broken test. By removing this early
return, lit ends up with the usual absolute path and everything works even
in this uncommon case.

llvm-svn: 330672

show more ...

[lit] Improve tool substitution in lit.

This addresses two sources of inconsistency in test configuration
files.

1. Substitution boundaries. Previously you would specify a
substitution, such as

[lit] Improve tool substitution in lit.

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

show more ...

Run pyformat on lit code.

llvm-svn: 315084

Resubmit "[lit] Refactor out some more common lit configuration code."

There were two issues, one Python 3 specific related to Unicode,
and another which is that the tool substitution for lld no lon

Resubmit "[lit] Refactor out some more common lit configuration code."

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

show more ...

Revert "[lit] Refactor out some more common lit configuration code."

This is breaking several bots. I have enough information to
investigate, so I'm reverting to green until I get it figured
out.

Revert "[lit] Refactor out some more common lit configuration code."

This is breaking several bots. I have enough information to
investigate, so I'm reverting to green until I get it figured
out.

llvm-svn: 313922

show more ...

[lit] Refactor out some more common lit configuration code.

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

[lit] Refactor out some more common lit configuration code.

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

show more ...

[lit] Add a test for the builtin config map.

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 co

[lit] Add a test for the builtin config map.

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

llvm-svn: 313887

show more ...

Resubmit "Add a shared llvm.lit module that all test suites can use."

There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
wo

Resubmit "Add a shared llvm.lit module that all test suites can use."

There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
work.

llvm-svn: 313467

show more ...

Revert lit changes related to lit.llvm module.

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 Pyt

Revert lit changes related to lit.llvm module.

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.

llvm-svn: 313429

show more ...

[lit] Fix another Python 3 error.

Apparently we have a buildbot running Python 3. This is going
to be fun :-/

llvm-svn: 313428

[lit] Better check for integral value.

Some versions of python don't have 'long'. Use numbers.Number
instead.

llvm-svn: 313427

Resubmit "[lit] Add a lit.llvm module that all llvm projects can use"

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

Resubmit "[lit] Add a lit.llvm module that all llvm projects can use"

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.

llvm-svn: 313426

show more ...

[lit] Revert "Add a lit.llvm module that all llvm projects can use"

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.

[lit] Revert "Add a lit.llvm module that all llvm projects can use"

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.

llvm-svn: 313328

show more ...

[lit] Add a lit.llvm module that all test suites can use.

To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functional

[lit] Add a lit.llvm module that all test suites can use.

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

llvm-svn: 313325

show more ...

[lit] Factor out listdir logic shared by different test formats.

Summary:
The lit test formats use largely the same logic for discovering tests. There are
some superficial differences in the logic,

[lit] Factor out listdir logic shared by different test formats.

Summary:
The lit test formats use largely the same logic for discovering tests. There are
some superficial differences in the logic, which seem reasonable enough to
handle in a single routine.

At a high level, the common goal is "look for files that end with one of these
suffixes, and skip anything starting with a dot." The balance of the logic
specific to ShTest and GoogleTest collapses quite a bit, so that
getTestsInDirectory is only a couple of lines around a call to the new function.

Reviewers: zturner, MatzeB, modocache

Subscribers: sanjoy, llvm-commits

Differential Revision: https://reviews.llvm.org/D34855

llvm-svn: 306895

show more ...

[lit] Re-apply: Fix some convoluted logic around Unicode encoding, and de-duplicate across modules that used it.

(Take 2: this patch re-applies r306625, which was reverted in r306629. This
patch inc

[lit] Re-apply: Fix some convoluted logic around Unicode encoding, and de-duplicate across modules that used it.

(Take 2: this patch re-applies r306625, which was reverted in r306629. This
patch includes only trivial fixes.)

In Python2 and Python3, the various (non-)?Unicode string types are sort of
spaghetti. Python2 has unicode support tacked on via the 'unicode' type, which
is distinct from 'str' (which are bytes). Python3 takes the "unicode-everywhere"
approach, with 'str' representing a Unicode string.

Both have a 'bytes' type. In Python3, it is the only way to represent raw bytes.
However, in Python2, 'bytes' is an alias for 'str'. This leads to interesting
problems when an interface requires a precise type, but has to run under both
Python2 and Python3.

The previous logic appeared to be correct in all cases, but went through more
layers of indirection than necessary. This change does the necessary conversions
in one shot, with documentation about which paths might be taken in Python2 or
Python3.

Changes from r306625: some tests just print binary outputs, so in those cases,
fall back to str() in Python3. For googletests, add one missing call to
to_string().

(Tested by verifying the visible breakage with Python3. Verified that everything
works in py2 and py3.)

llvm-svn: 306643

show more ...

Revert "[lit] Fix some convoluted logic around Unicode encoding, and de-duplicate across modules that used it."

This reverts r306625.

llvm-svn: 306629

Fix spelling: uncode -> unicode.

Remember kids: there is no 'I' in str or bytes, but there is ALWAYS an
'I' in unicode.

llvm-svn: 306626

[lit] Fix some convoluted logic around Unicode encoding, and de-duplicate across modules that used it.

Summary:
In Python2 and Python3, the various (non-)?Unicode string types are sort of
spaghetti.

[lit] Fix some convoluted logic around Unicode encoding, and de-duplicate across modules that used it.

Summary:
In Python2 and Python3, the various (non-)?Unicode string types are sort of
spaghetti. Python2 has unicode support tacked on via the 'unicode' type, which
is distinct from 'str' (which are bytes). Python3 takes the "unicode-everywhere"
approach, with 'str' representing a Unicode string.

Both have a 'bytes' type. In Python3, it is the only way to represent raw bytes.
However, in Python2, 'bytes' is an alias for 'str'. This leads to interesting
problems when an interface requires a precise type, but has to run under both
Python2 and Python3.

The previous logic appeared to be correct in all cases, but went through more
layers of indirection than necessary. This change does the necessary conversions
in one shot, with documentation about which paths might be taken in Python2 or
Python3.

Reviewers: zturner, modocache

Subscribers: llvm-commits, sanjoy

Differential Revision: https://reviews.llvm.org/D34793

llvm-svn: 306625

show more ...

[lit][macOS] Add a utility function to find the platform SDK version
on macOS

This function will be used to tie Clang's Integeration tests to a particular
SDK version. See https://reviews.llvm.org/D

[lit][macOS] Add a utility function to find the platform SDK version
on macOS

This function will be used to tie Clang's Integeration tests to a particular
SDK version. See https://reviews.llvm.org/D32178 for more context.

llvm-svn: 304541

show more ...