This change updates BooleanExpression (used in REQUIRES or UNSUPPORTED) to have
an additional ability for comparison. For example you can have
REQUIRES: something > <integer>
Where the comparison can be any of the usual ones (<,>,<=,>=,==,!=)
Paths
| Differential D154594
Add version comparison in BooleanExpression for lit testing Needs ReviewPublic Authored by dstuttard on Jul 6 2023, 4:08 AM.
Details
Diff Detail
Unit TestsFailed
Event TimelineComment Actions Something like this would be extremely useful in the libc++ test suite! However, IMO it would be a lot more useful if we could:
In fact, after that, I don't think we need the available_versions part of the config anymore. You just add a substitution like %{a-version} and then you just have to check for %{a-version} > 4. WDYT? Comment Actions I don't think substitutions are expanded on REQUIRES and UNSUPPORTED lines. It's an interesting suggestion though - I'll take a look and see how easy that is. Comment Actions I think it would be quite an invasive change to apply substitutions to lines other than RUN It would require the following changes: I'm not that familiar with this codebase, so I might be wrong. I could add the ability to compare strings to the current implementation if you are prepared to accept the available_versions addition instead? Comment Actions
Is there any reason lit cannot require REQUIRES, XFAIL, etc. to appear before all RUN, DEFINE, and REDEFINE? About the patch in general.... It seems these directives are heading in the same direction as RUN has been (see the PYTHON directive proposal for an alternative in that case). That is, we're incrementally developing our own full-blown expression language, and we still want more. Could we use python's eval to accept python's syntax instead? My only concern about using python in this case is that the syntax would likely become more verbose. For example, XFAIL: target=powerpc{{.*}}, system-darwin might become XFAIL-PY: re.match('powerpc.*', lit.target) or lit.has('system-darwin') However, now I don't have to figure out what , means in the case of XFAIL as it's explicit in python, and I can immediately build arbitrarily complex expressions, including integer and string comparisons. For substitutions, I'm proposing lit.expand in PYTHON directives, and we could use that here too. As in the case of PYTHON directives, I feel using python would lower the learning curve for lit users, reduce the burden for lit developers and reviewers, and significantly increase the power of these expressions. Again, the syntax would likely have to be more verbose, but that currently seems to me like a minor concern in comparison.
Revision Contents
Diff 537658 llvm/utils/lit/lit/BooleanExpression.py
llvm/utils/lit/lit/Test.py
llvm/utils/lit/lit/TestingConfig.py
llvm/utils/lit/tests/Inputs/show-used-features/mixed.txt
llvm/utils/lit/tests/Inputs/shtest-format/lit.cfg
llvm/utils/lit/tests/Inputs/shtest-format/version-missing.txt
llvm/utils/lit/tests/Inputs/shtest-format/version-present.txt
llvm/utils/lit/tests/Inputs/shtest-format/version-unfulfilled.txt
llvm/utils/lit/tests/Inputs/shtest-format/version-unsupported-false.txt
llvm/utils/lit/tests/Inputs/shtest-format/version-unsupported-true.txt
llvm/utils/lit/tests/shtest-format.py
|