This is an archive of the discontinued LLVM Phabricator instance.

Add version comparison in BooleanExpression for lit testing
Needs ReviewPublic

Authored by dstuttard on Jul 6 2023, 4:08 AM.

Details

Reviewers
ldionne
yln
jdenny
Summary

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 (<,>,<=,>=,==,!=)

Diff Detail

Unit TestsFailed

Event Timeline

dstuttard created this revision.Jul 6 2023, 4:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 6 2023, 4:08 AM
Herald added a subscriber: delcypher. · View Herald Transcript
dstuttard requested review of this revision.Jul 6 2023, 4:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 6 2023, 4:08 AM

Something like this would be extremely useful in the libc++ test suite! However, IMO it would be a lot more useful if we could:

  1. Expand substitutions in these expressions (do we do that?)
  2. Do string matching as well. That way I could do something like REQUIRES: %{stdlib} == libcxx. I wouldn't actually do that exactly, but you get the point.

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?

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.

I think it would be quite an invasive change to apply substitutions to lines other than RUN

It would require the following changes:
REQUIRES, UNSUPPORTED etc are dealt with during the parseIntegratedTestScript phase at the moment - that would have to change (increasing execution time - and may surface some issues).
REQUIRES etc are global - whereas substitutions are not - and can be changed as the script runs. What version of the substitution should apply, I guess it could be the context of the actual REQUIRES/UNSUPPORTED (this would require more significant changes to the file though as these would require tracking in the same way as RUN and DEFINE/REDEFINE etc).

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?

REQUIRES etc are global - whereas substitutions are not - and can be changed as the script runs. What version of the substitution should apply, I guess it could be the context of the actual REQUIRES/UNSUPPORTED (this would require more significant changes to the file though as these would require tracking in the same way as RUN and DEFINE/REDEFINE etc).

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.