This is an archive of the discontinued LLVM Phabricator instance.

[lit] Extend --xfail/LIT_XFAIL to take full test name
ClosedPublic

Authored by jdenny on Jun 30 2021, 9:45 AM.

Details

Summary

The new documentation entry gives an example use case from
libomptarget.

Diff Detail

Event Timeline

jdenny created this revision.Jun 30 2021, 9:45 AM
jdenny requested review of this revision.Jun 30 2021, 9:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2021, 9:45 AM

Since you refer to libomptarget, I'm wondering how you want to use this.
Do you plan to use this for manual lit invocation only or is the plan to hard-wire this option into check targets?

Since you refer to libomptarget, I'm wondering how you want to use this.
Do you plan to use this for manual lit invocation only or is the plan to hard-wire this option into check targets?

The former. My use case is my own CI config. That is, there are some upstream tests that fail, and there are people investigating to fix them, but it can take a long time. While I'm waiting, I want my CI to be green so I can easily see problems from patches I'm working on. I use these options in my CI config to achieve that.

This patch just makes it possible to be more precise in specifying tests. I cc'ed you because it's relevant after your D101326 (a nice improvement, BTW).

For background, D96662 has the original --xfail/LIT_XFAIL review.

yln accepted this revision.Jun 30 2021, 12:14 PM

This patch just makes it possible to be more precise in specifying tests.

My understanding of this change: a test file/declaration can produce multiple test executions (by being included in multiple test configurations). Previously, we could only xfail based on test name (suite-relative file path), which meant "all or none" test executions. This patch allows us to also use the fully-qualified test execution name (which includes the test configuration) to be more selective.

LGTM! Thanks also for the really good documentation! :)

(One thought I had: we could generalize this further by only requiring a substring match instead of an exact match on file_path or full_name; but probably no need for this right now.)

This revision is now accepted and ready to land.Jun 30 2021, 12:14 PM

This patch just makes it possible to be more precise in specifying tests.

My understanding of this change: a test file/declaration can produce multiple test executions (by being included in multiple test configurations).

It's also conceivable that the same file name might happen to appear in unrelated test suites, but I don't recall actually running into that case.

Previously, we could only xfail based on test name (suite-relative file path), which meant "all or none" test executions. This patch allows us to also use the fully-qualified test execution name (which includes the test configuration) to be more selective.

Exactly.

LGTM! Thanks also for the really good documentation! :)

Thanks for the quick review! Before pushing, I'll give @davezarzycki a few days to comment as the --xfail implementation was his.

(One thought I had: we could generalize this further by only requiring a substring match instead of an exact match on file_path or full_name; but probably no need for this right now.)

That's something to think about, but I'm not sure. My concern is additional unintentional collisions: foo.c would match my/foo.c, my/foo.cpp, and your/foo.c. I feel like suppressing test failures ought to be precise, and I think that's why @davezarzycki decided against regexes here.

jhenderson accepted this revision.Jul 1 2021, 12:32 AM

LGTM too.

(One thought I had: we could generalize this further by only requiring a substring match instead of an exact match on file_path or full_name; but probably no need for this right now.)

That's something to think about, but I'm not sure. My concern is additional unintentional collisions: foo.c would match my/foo.c, my/foo.cpp, and your/foo.c. I feel like suppressing test failures ought to be precise, and I think that's why @davezarzycki decided against regexes here.

Yeah, we need to be VERY careful with substring matches, due to the risk of false XFAILs for tests that should be real failures. We don't want real test failures be hidden by accident after all.

LGTM too. And I agree that substring matching would be undesirable.

davezarzycki accepted this revision.Jul 1 2021, 3:32 AM
This revision was automatically updated to reflect the committed changes.

Thanks for the reviews.