This is an archive of the discontinued LLVM Phabricator instance.

[lit] Stop supporting triple substrings in UNSUPPORTED and XFAIL
ClosedPublic

Authored by probinson on Jan 4 2023, 11:39 AM.

Details

Summary

AFAICT all in-tree lit tests have been converted to use target=...
and so there is no longer any need for triples being special.
Some project config files still define their own features based on
the triple, but those are normal feature words (although now are
redundant with target= checks).

https://discourse.llvm.org/t/rfc-lits-requires-and-triples/66041

Diff Detail

Event Timeline

probinson created this revision.Jan 4 2023, 11:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 11:39 AM
Herald added a subscriber: delcypher. · View Herald Transcript
probinson requested review of this revision.Jan 4 2023, 11:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 11:39 AM
yln added a comment.Jan 17 2023, 11:12 AM

Thanks so much for this effort and seeing it through! I think this materially improves LIT feature handling and reduces confusion.

I had just one question: what kind of testing did we do / how did we discover all uses of the triple substring matches?
To reduce churn and the probability that this gets reverted, can we add a short explanation to the commit message that explains how patterns like UNSUPPORTED: arm64 should be changed and maybe a link to the commit that did this for an existing example.

Thanks so much again!

yln accepted this revision.Jan 17 2023, 11:18 AM
This revision is now accepted and ready to land.Jan 17 2023, 11:18 AM

I agree with @yln , thanks a lot for pushing this through.

One thing to keep in mind here is that folks who rebase patches on top of this patch may get bitten by this issue for a couple weeks, so it may be worth grepping for suspicious patches from time to time, or turning this into an explicit error instead (just for a few weeks).

I had just one question: what kind of testing did we do / how did we discover all uses of the triple substring matches?

I wrote a patch to lit that would complain about undefined features. This was quite a bit of work as it mean changing config.available_features from a list to a dict, and then every place that used to do something like

if some_condition:
  config.available_features.add('name')

became instead

config.available_features['name'] = bool(some_condition)

and then BooleanExpression would complain if it found a (non-regex) feature name that wasn't in the dict. Some of these were simply typos, which I fixed; some were made-up words that meant "false"; and the rest (some hundreds, I don't remember the exact count) were triple substrings. I converted these to use target= over the course of about 50-60 individual patches.

I plan to run that again, now that everything _should_ be converted, to catch the last few, and then commit this patch.

The wonderful thing is, when this patch goes in, there can be no silent problems. Any remaining "mistakes" will actually cause test failures and be noticed. Anything that was XFAIL: substring will be treated as XFAIL: false and the test will fail. Anything that was UNSUPPORTED: substring will be treated as UNSUPPORTED: false and the test will run (and presumably fail).

To reduce churn and the probability that this gets reverted, can we add a short explanation to the commit message that explains how patterns like UNSUPPORTED: arm64 should be changed and maybe a link to the commit that did this for an existing example.

I can do that.

One thing to keep in mind here is that folks who rebase patches on top of this patch may get bitten by this issue for a couple weeks, so it may be worth grepping for suspicious patches from time to time, or turning this into an explicit error instead (just for a few weeks).

As I mentioned in the previous comment, any remaining (or future) mistakes will cause test problems and should be sorted out pretty much immediately.

I will post a reply to the Announcements version of description, so anyone following Discourse should see it.

This revision was landed with ongoing or failed builds.Jan 19 2023, 8:35 AM
This revision was automatically updated to reflect the committed changes.

Examples added to the commit log.
Entry made in release notes.
I will keep an eye out for bot fail-mail related to this change.

Thanks!