GitLab

optasm succeeds on x86_64-unknown-linux

don't expect failure on x86_64-unknown-linux for optasm/profasm

Add Jan-Willem Maessen's hash table test

expect fail for profasm too.

Hugs only: these all exhaust Hugs's heap, so make life_space_leak an
expected failure (CAF leak), and skip andre_monad, barton-mangler-bug
and jules_xref.

GHC-only tests:
	signals002	uses Handlers
	forkprocess01	forkProcess
	timeexts001	tests obsolete library
	net002		non-blocking I/O
	thurston-modular-arith	GHC-only scoped type variables

these take too long under Hugs

mark groups of tests as GHC-only, as they test GHC-specific features.

Expect no failures anymore

Don't expect fail on OpenBSD. We don't produce the floating point errors.

Testsuite cleaning.

remove dependencies on hslibs packages

remove obsolete test

Added support for testing generation and compilation of External Core
code. There are two new ways, which are not automatically enabled but can be
invoked from the command line: extcore and optextcore. Invoking either way will
test that ghc is able to generate External Core code for a given test, read the
code back in, and compile it to an executable that produces the expected output
for the test.

The External Core facility has a few limitations which result in certain tests
failing for the "extcore" way.
  - External Core can't represent foreign calls other than static C calls
  - External Core can't correctly represent literals resulting from a
    "foreign label" declaration
  - External Core can't represent declarations of datatypes with no
    constructors
The first of these was already known, and GHC panics if you tried to
generate External Core for a program containing such a call. The second two
cases were not handled properly before now; in another commit, I've changed the
code that emits External Core to panic if either of them arises. Previously,
GHC would happily generate External Core in either case, but would not be able
to compile the resulting code.

There are several tests that exhibit these limitations of External Core, so
they've had to be made "expected failures" when compiling in the extcore or
optextcore ways.

This test is an expected failure, but its original purpose seems to
have been lost along the way somewhere.

It is indeed failing, but I susepct not for the same reasons that it
was originally failing.  After fixing a few compilation errors I
managed to get it to run, whereupon it fails with "Prelude.read: no
parse", which may or may not be the correct result.  As far as I can
tell, this test never worked.  In the previous incarnation of the test
suite, it was even disabled.

Reclassify these test failures as "expected failures".  We are now at
ZBB (zero bug bounce).

omit GHCi way

Add output

Add Joaos circular program

Fix framework errors in this test

Add missing test.T for this test.

wibble

Fixes for framework errors (strange, I though I fixed these yesterday
before committing...)

wibble

Revamp the testsuite framework.  The previous framework was an
experiment that got a little out of control - a whole new language
with an interpreter written in Haskell was rather heavyweight and left
us with a maintenance problem.

So the new test driver is written in Python.  The downside is that you
need Python to run the testsuite, but we don't think that's too big a
problem since it only affects developers and Python installs pretty
easily onto everything these days.

Highlights:

  - 790 lines of Python, vs. 5300 lines of Haskell + 720 lines of
    <strange made-up language>.

  - the framework supports running tests in various "ways", which should
    catch more bugs.  By default, each test is run in three ways:
    normal, -O, and -O -fasm.  Additionally, if profiling libraries
    have been built, another way (-O -prof -auto-all) is added.  I plan
    to also add a 'GHCi' way.

    Running tests multiple ways has already shown up some new bugs!

  - documentation is in the README file and is somewhat improved.

  - the framework is rather less GHC-specific, and could without much
    difficulty be coaxed into using other compilers.  Most of the
    GHC-specificness is in a separate configuration file (config/ghc).

Things may need a while to settle down.  Expect some unexpected
failures.

This module had what looked like a lot of unnecessary (and now
deprecated) coercions from Word->Int and back, so I removed them.

PrelBase ==> GHC.Exts

Use HsInt rather than int
MERGE TO STABLE

Skip the test on alpha-dec-osf3, where we
run into an infinite loop on some builds

MERGE TO STABLE

On alpha-dec-osf3, we need to compile galois_raytrace with -O to
prevent the following fatality:

ghc-5.02: panic! (the `impossible' happened, GHC version 5.02):
	Oversize heap check detected.  Please try compiling with -O.

MERGE TO STABLE

Back out the change to remove Ord as a superclass of Ix; the revised
Haskell 98 report will no longer have this change.

Fix some signatures after Ord was removed as a superclass of Ix.

Fix some signatures after the change to the Ix class.

The program runs in its own directory now, so doesn't need hackage to
find its input file.

program runs in its own directory now, so doesn't need hackage to find
its input file.

Add Thurstons modular arith

the stubs shouldn't be in the repository

Add Makefiles for these tests

make this an expected failure

This test is an expected failure.  We have no idea how to run it.