This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] - Simplify HandleExpectedError implementation in DWARFDebugInfoTest
ClosedPublic

Authored by grimar on Jun 28 2017, 2:23 AM.

Details

Summary

Current implementation looks confusing. It looks like it should
report/print something on error, but it does not do that.

HandleExpectedError used to check targets created from triple.
I am not sure what was intended behavior,
current one - it does not print anything if target was not created and assumes
that test pass.

That behavior looks correct for me though, but then implementation can be simplified,
like this patch do. I think current behavior is correct because of next:
I tried to configure LLVM with -DLLVM_TARGETS_TO_BUILD=ARM and debugged the testcase under
windows. Triple I had was "i386-pc-windows-msvc". Testcase uses getHostTripleForAddrSize() to get
target triple. As expected for my configuration no tests were executed. For me it is looks fine in that case.

Diff Detail

Event Timeline

grimar created this revision.Jun 28 2017, 2:23 AM
dblaikie edited edge metadata.Jun 28 2017, 8:08 AM

I don't quite follow your description - this looks like it would print error messages, if the llvm::Error has a textual message (which not all do). I would expect the behavior should perhaps flip the other way - fix it so it does print a message even if the llvm::Error doesn't have a textual message itself? (I think llvm::Error has a more general tool for textual repreesntation, rather than just the message? Not sure)

zturner added inline comments.
unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
98–99

I recently added some functions to llvm that server this purpose better. I would suggest just deleting this function, and adding this:

#include "llvm/Testing/Support/Error.h"
...
ASSERT_THAT_EXPECTED(ExpectedDG, Succeeded());

I don't quite follow your description - this looks like it would print error messages, if the llvm::Error has a textual message (which not all do). I would expect the behavior should perhaps flip the other way - fix it so it does print a message even if the llvm::Error doesn't have a textual message itself? (I think llvm::Error has a more general tool for textual repreesntation, rather than just the message? Not sure)

What I was mean that

if (!ErrorMsg.empty()) {
  ::testing::AssertionFailure() << "error: " << ErrorMsg;
  return true;
}

creates temporarily object AssertionResult and calls operator<<. That does not print any messages. Object is destroyed after call and all messages
it contains inside after << are dying with it silently. And at first look it seems that method should assert, but this object never used.
So I believe code is equal to what I wrote in this patch.

grimar added inline comments.Jun 28 2017, 8:22 AM
unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
98–99

I'll take a look what ASSERT_THAT_EXPECTED do. If I got correctly from quivk look, that might be a better solution, really. Thanks !

grimar added inline comments.Jun 29 2017, 4:51 AM
unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
98–99

After closer look I think ASSERT_THAT_EXPECTED will not work here.

ASSERT_THAT_EXPECTED fails the test if ExpectedDG not exist:

error: Value of: llvm::detail::TakeExpected(ExpectedDG)
Expected: succeeded
  Actual: failed  (: error: unable to get target for 'i386-pc-windows-msvc', see
 --version and --triple.)
[  FAILED  ] DWARFDebugInfo.TestDWARF32Version2Addr4AllForms (115792 ms)

But what code expected to do is to pass the test in this case.

grimar added inline comments.Jun 29 2017, 4:57 AM
unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
98–99

So to clarify: if ExpectedDG is exist, test should continue and run, if not - test should terminate with success result, that is how current code works.

grimar updated this revision to Diff 104671.Jun 29 2017, 10:08 AM
  • Addressed review comments (introduced isConfigurationSupported() to be a ble to skip test early).
zturner accepted this revision.Jun 29 2017, 10:16 AM

lgtm. I have some other ideas for how to improve this test in the future, but mostly orthogonal to this effort (for example, why can't we just enumerate the cases that we expect to work based on the TargetRegistry, and then only run those tests?)

Might be a nice cleanup if you feel like it (or there might be some reason I can't think of why it wouldn't work the way I imagine), but feel free to do it in a follow-up (or not at all, purely optional)

This revision is now accepted and ready to land.Jun 29 2017, 10:16 AM

lgtm. I have some other ideas for how to improve this test in the future, but mostly orthogonal to this effort (for example, why can't we just enumerate the cases that we expect to work based on the TargetRegistry, and then only run those tests?)

Might be a nice cleanup if you feel like it (or there might be some reason I can't think of why it wouldn't work the way I imagine), but feel free to do it in a follow-up (or not at all, purely optional)

Thanks for review. Idea looks interesting for me. I am not so familar with gtest yet. I read gtest doc and reviewed implementation today, but did not yet found how to filter out tests with some custom predicate.
I see that gtest allows filtering by name, that is probably not what can help here. I think that all what is needed is to set TestInfo::is_disabled_ flag basing on custom user predicate somehow.
I'll try to revisit it more attentively a bit later, probably I am missed something.

grimar closed this revision.Jun 30 2017, 3:10 AM

r306812