daniel.is.fischer at googlemail.com
Thu May 12 16:59:01 CEST 2011
Running the testsuite with today's HEAD (perf build, but without profiling
to keep time bearable) resulted in:
OVERALL SUMMARY for test run started at Do 12. Mai 13:34:13 CEST 2011
2765 total tests, which gave rise to
9300 test cases, of which
0 caused framework failures
1587 were skipped
7467 expected passes
229 expected failures
9 unexpected passes
8 unexpected failures
Pretty cool, I can't remember having so few unexpected failures before.
That's the compiler not complaining about an INLINE-pragma on a class
method without default implementation. Patch is in ghc-generics branch, not
yet in master, according to #5084. Anyway it's nothing serious (was a
feature request, not a bug).
These are due to a missing Show instance for [:Int:], a library issue.
Fails with "dph-words-opt: libraries/vector/Data/Vector/Generic.hs:369
(slice): invalid slice (1,2,2)".
No idea whether that's a library or a compiler issue.
Those are due to hpc looking in the wrong directory for the tix files,
patch exists, but is not yet in the master branch, according to #5069.
So, of the eight unexpected failures, six are due to trivia (they *might*
fail for other causes when the trivia are fixed, but there's no reason to
expect that), one is a feature request whose test reached testsuite/master
before the implementation reached ghc/master and only one may (but need
not) indicate a compiler bug at present, that's rather awesome.
All these involve the new MonadComprehensions extension, they're expected
to work and do so for the normal and optasm ways, maybe they should also be
expected to work for hpc and ghci.
Additionally, sometimes conc016(threaded2) passes unexpectedly; which
thread first gets its exception to the other one is impossible to predict:
-- NB. this test is delicate since 6.14, because throwTo is now always
-- interruptible, so the main thread's killThread can be legitimately
-- interrupted by the child thread's killThread, rather than the other
-- way around. This happens because the child thread is running on
-- another processor, so the main thread's throwTo is blocked waiting
-- for a response, and while waiting it is interruptible.
Summing up: Yay!
More information about the Glasgow-haskell-users