[lit] Support %if ... %else syntax for RUN lines

This syntax allows to modify RUN lines based on features
available. For example:

RUN: ... | FileCheck %s --check-prefix=%if windows %{CHECK-W%}

[lit] Support %if ... %else syntax for RUN lines

This syntax allows to modify RUN lines based on features
available. For example:

RUN: ... | FileCheck %s --check-prefix=%if windows %{CHECK-W%} %else %{CHECK-NON-W%}
CHECK-W: ...
CHECK-NON-W: ...

The whole command can be put under %if ... %else:

RUN: %if tool_available %{ %tool %} %else %{ true %}

or:

RUN: %if tool_available %{ %tool %}

If tool_available feature is missing, we'll have an empty command in
this RUN line. LIT used to emit an error for empty commands, but now
it treats such commands as nop in all cases.

Multi-line expressions are also supported:

RUN: %if tool_available %{ \
RUN: %tool \
RUN: %} %else %{ \
RUN: true \
RUN: %}

Background and motivation:
D121727 [NVPTX] Integrate ptxas to LIT tests
https://reviews.llvm.org/D121727

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

show more ...

[test] Add lit helper for windows paths

This adds 2 new lit helpers `%{fs-src-root}` and `%{fs-sep}`, these
allow writing tests that correctly handle slashes on Windows. In the
case of tests like cl

[test] Add lit helper for windows paths

This adds 2 new lit helpers `%{fs-src-root}` and `%{fs-sep}`, these
allow writing tests that correctly handle slashes on Windows. In the
case of tests like clang/test/CodeGen/debug-prefix-map.c, these are
unable to correctly test behavior on both platforms, unless they fork
and add OS requirements, because the relevant logic hits host specific
codepaths like checking if paths are absolute.

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

show more ...

[docs] Replace `opt -analyze` with better alternatives.

`opt -analyze` is legacy PM-specific. Show better ways of doing the same
thing, generally with some sort of `-passes=print<foo>`.

Reviewed By

[docs] Replace `opt -analyze` with better alternatives.

`opt -analyze` is legacy PM-specific. Show better ways of doing the same
thing, generally with some sort of `-passes=print<foo>`.

Reviewed By: asbirlea

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

show more ...

[llvm][docs] Fix code-block in the testing guide

Without a langauge name it's an error (with some verisons of Sphinx
it seems) or the block is simply missing in the output.

[docs] Mention --leading-lines instead of --no-leading-lines

[Docs] Document scripts that are use to generate assertion in test cases

This patch document llvm/utils/update_* python scripts that are used to generate
assertions in many of the LLVM regression t

[Docs] Document scripts that are use to generate assertion in test cases

This patch document llvm/utils/update_* python scripts that are used to generate
assertions in many of the LLVM regression test cases.

Reviewed By: MaskRay

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

show more ...

llvm doc: remove the old reference to subversion and add a link to the GH repo instead

Adjust the doc after the renaming of debuginfo-tests => cross-project-tests

[docs] Document that psutil should be installed in non-user location

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

Revert "Reapply "[lit] Have REQUIRES support the target triple""

This reverts commit 187c69e9efcf2f595943412f21e8ba58de749a22.
compiler-rt/test/cross_over_uniform_dist.test refuses to pass.

Reapply "[lit] Have REQUIRES support the target triple"

This reverts commit 3229c971512404c512e041c3e88f22dbec2b650b.

With a2acac6 in place this should provide enough info to work out
any repeat of

Reapply "[lit] Have REQUIRES support the target triple"

This reverts commit 3229c971512404c512e041c3e88f22dbec2b650b.

With a2acac6 in place this should provide enough info to work out
any repeat of the failure in cross_ovver_uniform_dist.test.

show more ...

Revert "[lit] Have REQUIRES support the target triple"

This reverts commit 100a7b6197863d4d5ebc97761d7e98063e164e26.

Speculating that this is the reason behind a sanitizer failure:
https://lab.llvm

Revert "[lit] Have REQUIRES support the target triple"

This reverts commit 100a7b6197863d4d5ebc97761d7e98063e164e26.

Speculating that this is the reason behind a sanitizer failure:
https://lab.llvm.org/buildbot/#/builders/37/builds/5945

show more ...

[lit] Have REQUIRES support the target triple

Currently the UNSUPPORTED and XFAIL clauses support specifying
substrings of the target triple; but REQUIRES does not, which can trip
people up or lead

[lit] Have REQUIRES support the target triple

Currently the UNSUPPORTED and XFAIL clauses support specifying
substrings of the target triple; but REQUIRES does not, which can trip
people up or lead to hacking config files to insert substitute feature
names. Consistency across all three lit clauses seems preferable.

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

show more ...

[lit] Add the ability to parse regexes in Lit boolean expressions

This patch augments Lit with the ability to parse regular expressions
in boolean expressions. This includes REQUIRES:, XFAIL:, UNSUP

[lit] Add the ability to parse regexes in Lit boolean expressions

This patch augments Lit with the ability to parse regular expressions
in boolean expressions. This includes REQUIRES:, XFAIL:, UNSUPPORTED:,
and all other special Lit markup that evaluates to a boolean expression.

Regular expressions can be specified by enclosing them in {{...}},
similarly to how FileCheck handles such regular expressions. The regular
expression can either be on its own, or it can be part of an identifier.
For example, a match expression like {{.+}}-apple-darwin{{.+}} would match
the following variables:

x86_64-apple-darwin20.0
arm64-apple-darwin20.0
arm64-apple-darwin22.0
etc...

In the long term, this could be used to remove the need to handle the
target triple specially when parsing boolean expressions.

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

show more ...

[RFC][debuginfo-test] Rename debug-info lit tests for general purposes

Discussion thread:
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148048.html

Move debuginfo-test into a subdirectory

[RFC][debuginfo-test] Rename debug-info lit tests for general purposes

Discussion thread:
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148048.html

Move debuginfo-test into a subdirectory of a new top-level directory,
called cross-project-tests. The new name replaces "debuginfo-test" as an
LLVM project enabled via LLVM_ENABLE_PROJECTS.

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

Reviewed by: aprantl

show more ...

[Docs] Update googletest docs link.

The documentation link of Google Test on GitHub have been moved to the
top-level docs directory.
Thus, the original link is invalid now.

Reviewed By: Pavel Labat

[Docs] Update googletest docs link.

The documentation link of Google Test on GitHub have been moved to the
top-level docs directory.
Thus, the original link is invalid now.

Reviewed By: Pavel Labath

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

show more ...

[test] Use host platform specific error message substitution in lit tests - continued

On z/OS, other error messages are not matched correctly in lit tests.

```
EDC5121I Invalid argument.
EDC5111I P

[test] Use host platform specific error message substitution in lit tests - continued

On z/OS, other error messages are not matched correctly in lit tests.

```
EDC5121I Invalid argument.
EDC5111I Permission denied.
```

This patch adds a lit substitution to fix it.

Reviewed By: jhenderson

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

show more ...

[test] Use host platform specific error message substitution in lit tests

On z/OS, the following error message is not matched correctly in lit tests.

```
EDC5129I No such file or directory.
```

Th

[test] Use host platform specific error message substitution in lit tests

On z/OS, the following error message is not matched correctly in lit tests.

```
EDC5129I No such file or directory.
```

This patch uses a lit config substitution to check for platform specific error messages.

Reviewed By: muiez, jhenderson

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

show more ...

Update references to 'master' branch.

This commit replace 'master' with 'main' in llvm/docs.

Reviewed By: sammccall, kristof.beyls

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

Remove Python2 fallback and only advertise Python3 in the doc

Differential Revision: https://www.youtube.com/watch?v=RsL0cipURA0

Add test utility 'split-file'

See https://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
"[llvm-dev] Multiple documents in one test file" for some discussions.

This patch has explored seve

Add test utility 'split-file'

See https://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
"[llvm-dev] Multiple documents in one test file" for some discussions.

This patch has explored several alternatives. The current semantics are similar to
what @dblaikie proposed.
`split-file filename output` splits the input file into multiple parts separated by
regex `^(.|//)--- filename` and write each part to the file `output/filename`
(`filename` can include path separators).

Use case A (organizing input of different formats (e.g. linker
script+assembly) in one file).

```
# RUN: split-file %s %t
# RUN: llvm-mc %t/asm -o %t.o
# RUN: ld.lld -T %t/lds %t.o -o %t
This is sometimes better than the %S/Inputs/ approach because the user
can see the auxiliary files immediately and don't have to open another file.

# asm
...
# lds
...
```

Use case B (for utilities which don't have built-in input splitting
feature):

```
// RUN: split-file %s %t
// RUN: llc < %t/1.ll | FileCheck %s --check-prefix=CASE1
// RUN: llc < %t/2.ll | FileCheck %s --check-prefix=CASE2
Combing tests prudently can improve readability.
For example, when testing parsing errors if the recovery mechanism isn't possible,
grouping the tests in one file can more readily see test coverage/strategy.

//--- 1.ll
...
//--- 2.ll
...
```

Since this is a new utility, there is no git history concerns for
UpperCase variable names. I use lowerCase variable names like mlir/lld.

Reviewed By: jhenderson, lattner

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

show more ...

Revert D83834 "Add test utility 'extract'"

This reverts commit d054c7ee2e9f4f98af7f22a5b00a941eb919bd59.

There are discussions about the utility name, its functionality and user interface.
Revert b

Revert D83834 "Add test utility 'extract'"

This reverts commit d054c7ee2e9f4f98af7f22a5b00a941eb919bd59.

There are discussions about the utility name, its functionality and user interface.
Revert before we reach consensus.

show more ...

Add test utility 'extract'

See https://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
"[llvm-dev] Multiple documents in one test file" for some discussions.

`extract part filename` splits

Add test utility 'extract'

See https://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
"[llvm-dev] Multiple documents in one test file" for some discussions.

`extract part filename` splits the input file into multiple parts separated by
regex `^(.|//)--- ` and extract the specified part to stdout or the
output file (if specified).

Use case A (organizing input of different formats (e.g. linker
script+assembly) in one file).

```
// RUN: extract lds %s -o %t.lds
// RUN: extract asm %s -o %t.s
// RUN: llvm-mc %t.s -o %t.o
// RUN: ld.lld -T %t.lds %t.o -o %t
This is sometimes better than the %S/Inputs/ approach because the user
can see the auxiliary files immediately and don't have to open another file.
```

Use case B (for utilities which don't have built-in input splitting
feature):

```
// RUN: extract case1 %s | llc | FileCheck %s --check-prefix=CASE1
// RUN: extract case2 %s | llc | FileCheck %s --check-prefix=CASE2
Combing tests prudently can improve readability.
This is sometimes better than having multiple test files.
```

Since this is a new utility, there is no git history concerns for
UpperCase variable names. I use lowerCase variable names like mlir/lld.

Reviewed By: jhenderson

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

show more ...

Document the testing of Analyses in the LLVM testing guide (NFC)

This came up in a recent review, someone was wondering were was
this all documented and I couldn't find a reference to provide.

Diff

Document the testing of Analyses in the LLVM testing guide (NFC)

This came up in a recent review, someone was wondering were was
this all documented and I couldn't find a reference to provide.

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

show more ...

NFC: Fix typos in TestingGuide documentation