This is an archive of the discontinued LLVM Phabricator instance.

Skip tests that are failed on linux with gcc-4.9.2
ClosedPublic

Authored by chying on Apr 6 2015, 7:34 PM.

Details

Summary
  • add decorator functions to skip test on specific os, architecture and version of comipler
  • skip failing test with gcc-4.9.2 on linux

Diff Detail

Repository
rL LLVM

Event Timeline

chying updated this revision to Diff 23305.Apr 6 2015, 7:34 PM
chying retitled this revision from to Skip tests that are failed on linux with gcc-4.9.2.
chying updated this object.
chying edited the test plan for this revision. (Show Details)
chying added a subscriber: Unknown Object (MLST).
sivachandra added inline comments.Apr 9 2015, 2:48 PM
test/lldbtest.py
740 ↗(On Diff #23305)

Could we just name this function "skipIf" and use it directly to decorate tests? May be we could eliminate all skipIf* decorators in favor of this, but I have not thought through that thoroughly. Atleast, it seems to me that things like skipIfLinuxGcc, skipIfGcc and skipIfClang can be eliminated. You will ofcourse have to change the logic in the 'fn' function below. And ofcourse you need not have to remove/modify the existing decorators in this patch itself.

One thing we might loose is the ability to "git grep xxx" to get all tests decorated with xxx.

chying added inline comments.Apr 9 2015, 4:13 PM
test/lldbtest.py
740 ↗(On Diff #23305)

yes, this function could be used to decorate tests directly as is.
Like @skipIf("bn", "linux", "gcc", ['>=','4.9'], ['i386','x86'])

My understanding is that by providing a various of wrapper functions like skipIfLinuxGcc, skipIfClang, we got better readability of code, and also as you mentioned, it's easier to find all tests decorated with certain compiler or host.
Maybe it's similar reasoning behind ExpectedFailureGcc/Icc/Clang

We could definitely re-factor current skipif* functions to call this function instead of having common code in each function.

sivachandra added inline comments.Apr 9 2015, 4:31 PM
test/lldbtest.py
740 ↗(On Diff #23305)

Please note that I am not taking ownership of this review. I do not have strong opinions about the changes and would like others to chime in and drive.

IMO, @skipIfLinuxGcc('bugnumber', ['>=', '4.9'], ['i386']) is not any more readable than @skipIf("bn", "linux", "gcc", ['>=','4.9'], ['i386','x86']).

Also, one can still git grep, but have to put slightly more effort. For example, instead of doing

git grep skipIfLinux

one will now have to do

git grep "skipIf(.*linux.*)"
labath added a subscriber: labath.Apr 10 2015, 2:15 AM

Slightly off topic, but I would like to ask what is the guideline for
using skipIf vs. expectedFailure? Do we have one? (If not maybe we
should make one)

I was under the impression that expectedFailureXXX is to be used for
tests that are failing due to a bug in LLDB, whereas skipIfXXX are for
situations where the test simply does not apply to the platform
environment in question (e.g. debugserver tests on linux, etc). If
that is the case, then these tests should be XFAILed rather then
skipped.
Is that so ?

For the readability issue, I would propose the following syntax:

@skipIf("bugnumber", lambda x: compilerIs("gcc>=4.9") &&
platformIs("linux") && architectureIs("aarch64", "x86_64"))

I think this would be more versatile that the previous solutions, and
you don't need to litter the code with so many decorators.
What do you think about that?

cheers,
pl

I think your understanding is correct, based on pytest documentation:
"A skip means that you expect your test to pass unless the environment (e.g. wrong Python interpreter, missing dependency) prevents it to run. And xfail means that your test can run but you expect it to fail because there is an implementation problem."

Do we know if all these failures are caused by lldb bugs or possibly gcc-4.9.2 bugs?

Another difference I would like to point out is that, the tests will still be run if marked as xfail.
And sometimes it takes longer to run failing tests. For example, TestMiExec.py takes 164s to complete with 4 errors(with gcc4.9.2 and i386). It makes the overall test time longer. That's why I chose skip over xfail here.

Using lambda functions is a good idea. We could potentially combine multiple decorators to one.
For example, @skipIf('bn', lambda:(platform(['FreeBSD'])) or (platform(['linux']) and compiler('gcc')))

Please let me know if anyone has different ideas.

emaste added a subscriber: emaste.Apr 13 2015, 11:49 AM

We could definitely re-factor current skipif* functions to call this function instead of having common code in each function.

Yes, we should at least do that. When I added FreeBSD support to the tests I spent some time to refactor the expectedFailure cases to avoid the copypasta, but for some reason didn't take on the skipIf tests. I don't have a strong opinion on skipIfFreeBSD vs skipIf(... "FreeBSD" ...)

I was under the impression that expectedFailureXXX is to be used for tests that are failing due to a bug in LLDB, whereas skipIfXXX are for situations where the test simply does not apply to the platform environment in question (e.g. debugserver tests on linux, etc).

Yes, this is consistent with my understanding, with the caveat that we also (ab)use skip for tests that take excessively long to fail / timeout, or that consistently crash (as that case is not conveniently handled by the infrastructure).

vharron accepted this revision.Apr 20 2015, 11:25 AM
vharron edited edge metadata.

Please make suggested changes and submit.

test/api/multithreaded/TestMultithreaded.py
36 ↗(On Diff #23305)

Agreeing with previous comments, these should be expectedFailureLinuxGcc

Since Gcc tests aren't run on OSX, should we assume these are just expectedFailureGcc?

test/functionalities/inferior-crashing/TestInferiorCrashing.py
82 ↗(On Diff #23305)

Did you forget brackets?

archs=["i386"]

This revision is now accepted and ready to land.Apr 20 2015, 11:25 AM
chying updated this revision to Diff 24084.Apr 20 2015, 5:15 PM
chying edited edge metadata.

Mark these tests with xfail instead of skip

-Add decorator to xfail specified platform/compiler/architecture

Since Gcc tests aren't run on OSX, should we assume these are just expectedFailureGcc?

Since the code will check against target platform, and we don't intend to xfail those tests with Android target, I added new xfail function to take platform and compiler and architecture.

sivachandra added inline comments.Apr 20 2015, 5:25 PM
test/lldbtest.py
758 ↗(On Diff #24084)

If this is dead code currently, I would suggest you use it atleast once. TestVectorTypesFormatting is a good candidate that I know of.

chying updated this revision to Diff 24089.Apr 20 2015, 6:16 PM

Add one usage of the new skipIf decorator as suggested.
Add more description of decorator usage.

This revision was automatically updated to reflect the committed changes.