[NFC][Py Reformat] Reformat python files in llvm

This is the first commit in a series that will reformat
all the python files in the LLVM repository.

Reformatting is done with `black`.

See more in

[NFC][Py Reformat] Reformat python files in llvm

This is the first commit in a series that will reformat
all the python files in the LLVM repository.

Reformatting is done with `black`.

See more information here:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: jhenderson, JDevlieghere, MatzeB

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

show more ...

[lit][NFC] not check stdout in googletest-timeout.py

This is flicky for buildbots (for example, https://lab.llvm.org/buildbot/#/builders/188/builds/21560)
because of the short timeout. The test cove

[lit][NFC] not check stdout in googletest-timeout.py

This is flicky for buildbots (for example, https://lab.llvm.org/buildbot/#/builders/188/builds/21560)
because of the short timeout. The test coverage is not reduced because
the stdout check is performed in other googtest-* unit tests.

show more ...

[lit][test] explicitly use utf-8 encoding to write testing json file

Related test failure:
https://lab.llvm.org/buildbot/#/builders/178/builds/2527/steps/13/logs/FAIL__lit___googletest-timeout_py

[lit] Keep stdout/stderr when using GoogleTest format

When a unit test crashes or timeout, print the shard's stdout and
stderr. When a unit test fails, attaches the test's output to the LIT
output t

[lit] Keep stdout/stderr when using GoogleTest format

When a unit test crashes or timeout, print the shard's stdout and
stderr. When a unit test fails, attaches the test's output to the LIT
output to help debugging.

While at it, concatenating shard's environment variables using space
instead of newline to make the reproducer script user friendly.

Based on D123797. (Thanks to @lenary)

show more ...

[Reland][lit] Use sharding for GoogleTest format

This helps lit unit test performance by a lot, especially on windows. The performance gain comes from launching one gtest executable for many subtest

[Reland][lit] Use sharding for GoogleTest format

This helps lit unit test performance by a lot, especially on windows. The performance gain comes from launching one gtest executable for many subtests instead of one (this is the current situation).

The shards are executed by the test runner and the results are stored in the
json format supported by the GoogleTest. Later in the test reporting stage,
all test results in the json file are retrieved to continue the test results
summary etc.

On my Win10 desktop, before this patch: `check-clang-unit`: 177s, `check-llvm-unit`: 38s; after this patch: `check-clang-unit`: 37s, `check-llvm-unit`: 11s.
On my Linux machine, before this patch: `check-clang-unit`: 46s, `check-llvm-unit`: 8s; after this patch: `check-clang-unit`: 7s, `check-llvm-unit`: 4s.

Reviewed By: yln, rnk, abrachet

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

show more ...

Revert "Reland "[lit] Use sharding for GoogleTest format""

This reverts commit 948f3deca91a66caf4a618f826ff6de8277bed9c.

Reland "[lit] Use sharding for GoogleTest format"

This relands commit a87ba5c86d5d72defdbcdb278baad6515ec99463.

Adjust llvm/utils/lit/tests/googletest-timeout.py for new test output.

[lit] Try to remove the flakeyness of `shtest-timeout.py` and `googletest-timeout.py`.

The tests previously relied on the `short.py` and `FirstTest.subTestA`
script being executed on a machine withi

[lit] Try to remove the flakeyness of `shtest-timeout.py` and `googletest-timeout.py`.

The tests previously relied on the `short.py` and `FirstTest.subTestA`
script being executed on a machine within a short time window (1 or 2
seconds). While this "seems to work" it can fail on resource constrained
machines. We could bump the timeout a little bit (bumping it too
much would mean the test would take a long time to execute) but it wouldn't
really solve the problem of the test being prone to failures.

This patch tries to remove this flakeyness by separating testing into
two separate parts:

1. Testing if a test can hit a timeout.
2. Testing if a test can run to completion in the presence of a
timeout.

This way we can give (1.) a really short timeout (to make the test run
as fast as possible) and (2.) a really long timeout. This means for (2.)
we are no longer trying to rely on the "short" test executing within
some short time window. Instead the window is now 3600 seconds which
should be long enough even for a heavily resource constrained machine to
execute the "short" test.

Thanks to Julian Lettner for suggesting this approach. This superseeds
my original approach in https://reviews.llvm.org/D88807.

This patch also changes the command line override test to run the quick
test rather than the slow one to make the test run faster.

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

show more ...

[lit] Port googletest lit tests to Windows

Summary:
The technique of directly calling subprocess.Popen on a python script
doesn't work on Windows. The executable path of the command must refer
to a

[lit] Port googletest lit tests to Windows

Summary:
The technique of directly calling subprocess.Popen on a python script
doesn't work on Windows. The executable path of the command must refer
to a valid win32 executable.

Instead, rename all the python scripts masquerading as gtest executables
to have .py extensions, so we can easily detect then and call the python
executable for them. Do this on Linux as well as Windows for
consistency.

The test suite directory names also come out in lower-case on Windows.
We can consider removing that in a later patch. This change just updates
the FileCheck lines to match on Windows.

Fixes PR33933

Reviewers: modocache, mgorny

Subscribers: llvm-commits

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

llvm-svn: 309347

show more ...