This is an archive of the discontinued LLVM Phabricator instance.

surface build error content through test event system
ClosedPublic

Authored by tfiala on May 13 2016, 11:56 AM.

Details

Summary

print build errors nicely in test output

This test infrastructure change adds a new Python exception
for test subject builds that fail. The output of the build
command is captured and propagated to both the textual test
output display code and to the test event system.

The ResultsFormatter objects have been modified to do something
more useful with this information. The xUnit formatter
now replaces the non-informative Python build error stacktrace
with the build error content. The curses ResultsFormatter
prints a 'B' for build errors rather than 'E'.

The xUnit output, in particular, makes it much easier for
developers to track down test subject build errors that cause
test failures when reports come in from CI.

Diff Detail

Repository
rL LLVM

Event Timeline

tfiala updated this revision to Diff 57229.May 13 2016, 11:56 AM
tfiala retitled this revision from to surface build error content through test event system.
tfiala updated this object.
tfiala added a reviewer: granata.enrico.
tfiala added a subscriber: llvm-commits.

This was my first time using arcanist to submit a code review with a git-svn setup. I'm trying to use that code workflow - expect possible workflow n00b issues throughout this review.

As an example of output, here's what the textual output for a (force, contrived) build error looks like now:

Configuration: arch=x86_64 compiler=clang
----------------------------------------------------------------------
Collected 2 tests

======================================================================
ERROR: test_typedef_dsym (Testtypedef.TypedefTestCase)
   Test 'image lookup -t a' and check for correct display at different scopes.
----------------------------------------------------------------------
Error when building test subject.

Test Directory:
/Volumes/Data/src/lldb-llvm.org/lldb/packages/Python/lldbsuite/test/lang/c/typedef

Build Command:
make MAKE_DSYM=YES ARCH=x86_64 CC="clang"

Build Output:
main.c:10:10: fatal error: 'idontexist.h' file not found
#include <idontexist.h>
         ^
1 error generated.
make: *** [main.o] Error 1

======================================================================
ERROR: test_typedef_dwarf (Testtypedef.TypedefTestCase)
   Test 'image lookup -t a' and check for correct display at different scopes.
----------------------------------------------------------------------
Error when building test subject.

Test Directory:
/Volumes/Data/src/lldb-llvm.org/lldb/packages/Python/lldbsuite/test/lang/c/typedef

Build Command:
make MAKE_DSYM=NO ARCH=x86_64 CC="clang"

Build Output:
main.c:10:10: fatal error: 'idontexist.h' file not found
#include <idontexist.h>
         ^
1 error generated.
make: *** [main.o] Error 1

----------------------------------------------------------------------
Ran 2 tests in 0.754s

RESULT: FAILED (0 passes, 0 failures, 2 errors, 0 skipped, 0 expected failures, 0 unexpected successes)
Session logs for test failures/errors/unexpected successes can be found in directory '2016-05-13-11_42_40'

That's much more informative as to what went wrong. Previously we'd just get a Python backtrace that said one of the build routines failed, with no output as to what build failure occurred.

granata.enrico added inline comments.May 13 2016, 2:54 PM
packages/Python/lldbsuite/test/lldbtest.py
422 ↗(On Diff #57229)

I don't have a strong opinion either way, this is just me offering an alternative

Does it make sense to have custom members on the CalledProcessError object? It is not a big deal, unless some of our member names conflict with ones that Python may want to use - but in general, if we think we may want to expand the set, is there any advantage to custom member variables vs. attaching a custom dictionary:

cpe.LLDB_test_build_error_data = {'output' : ... }

Up to you really. I have seen and used both styles at different times.

packages/Python/lldbsuite/test/plugins/builder_base.py
109 ↗(On Diff #57229)

Could we make BuildError's init take a CalledProcessError directly, and extract data out of it as it sees fit?

packages/Python/lldbsuite/test/test_result.py
145 ↗(On Diff #57229)

I would use isinstance() here

160 ↗(On Diff #57229)

Could this be done by adding a str() or repr() method on BuildError instead?

packages/Python/lldbsuite/test_event/build_exception.py
6 ↗(On Diff #57229)

Newline at the end :-)

Great feedback. I'll address them in a follow-up patch.

packages/Python/lldbsuite/test/lldbtest.py
422 ↗(On Diff #57229)

Sure, dictionary sounds fine.

Effective Python (IIRC) recommended against making member accessors on the basis of there is no real protection against direct access to the members. But the dictionary seems reasonable.

packages/Python/lldbsuite/test/plugins/builder_base.py
109 ↗(On Diff #57229)

Yes, I like that idea.

packages/Python/lldbsuite/test/test_result.py
145 ↗(On Diff #57229)

Okay, I'll have a look at that. I know None behaves properly with type(), not sure if it does with isinstance().

160 ↗(On Diff #57229)

Sure. Removes duplication in another location (xUnit formatter). Good call.

packages/Python/lldbsuite/test_event/build_exception.py
6 ↗(On Diff #57229)

Ah yes. I unintentionally forgot to add this initially (git add was forgotten), and I blew it away when preparing to put this up for review. This one I rewrote too fast.

tfiala updated this revision to Diff 57274.May 13 2016, 5:39 PM
  • Merge remote-tracking branch 'origin/master' into surface-build-error
  • changes per review from Enrico
tfiala marked 4 inline comments as done.May 13 2016, 5:42 PM

I think I hit all the comments you indicated with the new patch set.

packages/Python/lldbsuite/test/test_result.py
145 ↗(On Diff #57229)

Yep none works fine here.

granata.enrico accepted this revision.May 13 2016, 5:42 PM
granata.enrico edited edge metadata.
This revision is now accepted and ready to land.May 13 2016, 5:42 PM
This revision was automatically updated to reflect the committed changes.