GitLab

This patch is based on a similar one "Enable timeout in Windows
and don't require cygwin python" by Esa Ilari Vuokko. It seems
like timeout is always built on Windows so I rearranged the logic
there to make the code clearer, Esa's patch required the user to
uncomment the MinGW-specific logic in order for it to work; this
patch does not have the MinGW-specific logic commented out.

I tested this on the trunk in Ubuntu 6.06 on i686 (VMWare).
I tested this on the trunk and ghc-6.6 branch on Windows i686.

As well as being generally a good idea, os.access('foo') seems to return
true if foo.exe exists on Windows.

I had to pull the global classes and instances out into their own module
as there was a catch-22: testlib needed to know if threading was enabled,
but we don't know that until we have gone through the argument, but going
through the arguments required changing things like config in testlib.

We need to call GHC.TopHandler.runIOFastExit instead of
GHC.TopHandler.runIO.  Recent fixes to the shutdown code have meant
that when a thread invokes shutdownHaskellAndExit(), other main
threads get a chance to exit (as they should), but this means that we
might have a race between the child thread trying to exit the program
and the main thread doing the same.  In the case of GHCi, if we're
running an interpreted computation that needs to exit (as some tests
do), then we really want this child thread to exit the program rather
than the main thread.

Before:
   tc056(normal)
   tc056(opt)
   tc056(optasm)
   tc056(prof)
   tc056(profasm)
   tc056(unreg)

After:
   tc056(normal,opt,optasm,prof,profasm,unreg)

Add a fast version of the testsuite

The idea is to have a way to run as much of the testsuite as possible
in a short time, so that we'll run it more often (such as just before
checking in a change, for example).  'make fast' tries for good
coverage without using too many cycles.  Currently it takes about 4
minutes on a fast machine with an optimised GHC build; I think this
might still be a little on the slow side.

When you say 'make fast' in testsuite/tests/ghc-regress, we run each
test only one way, and all of the long-running tests are omitted.
Also, to get the runtime down further, I arbitrarily omitted many of
the should_run tests (because these tend to take a lot longer than
should_compile or should_fail tests).  I tried to keep a
representative few in each category.

Infrastructure for testing Data structures.
 + some tests

tiny fix to simple_run(), adding a space between args and rts_flags.

interpter_run: add ">> return ()", to avoid GHCi trying to print
out (and evaluate) the result of Main.main.

Add skip_if_no_ghci

Disable the use of the timeout wrapper on Windows for now; it runs the
command using the wrong shell.

slight correction to runCmd to fix exit code values.

Add a timeout to test runs, using a wrapper program (written in
Haskell, using System.Process of course!).

More compiler_type support: added the option functions

	omit_compiler_types(compilers)
			      skip this test for certain compilers
	only_compiler_types(compilers)
			      do this test for certain compilers only
	expect_fail_if_compiler_type(compiler)
			      expect failure from a certain compiler

and also use output files ending in -<compiler_type> if present.

small fix for GHCi tests on Windows

Testsuite cleaning.

More Windows fixes

Test driver fixes for Windows.

Fix GHCi tests on Windows.

Allows a -ws-64 stdout variant rather than requiring each 64-bit
platform to have a -platform one. (You now need to make boot in
testsuite after configure but before running tests).

Modify enum001, partly to alter spacing but also to inline printTest
where things like \NUL are used, as modern cpp behaves differently.

Rename the generated .script files to .genscript to make it easier to
clean a testsuite tree.

Hack around \r\n vs. \n differences in sample output on Windows.

Skip the GHCi tests if ghci is not in run_ways.

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.

Check exit codes from GHCi runs (we were ignoring them before).

merge to STABLE