1. 14 Dec, 2006 3 commits
  2. 09 Dec, 2006 1 commit
  3. 18 Sep, 2006 1 commit
  4. 25 Oct, 2006 1 commit
  5. 13 Oct, 2006 1 commit
  6. 17 Sep, 2006 1 commit
    • brianlsmith's avatar
      Allow testsuite to run under MSYS/MinGW using native Python (not Cygwin Python). · e1bdf63f
      brianlsmith authored
      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.
      e1bdf63f
  7. 10 Sep, 2006 2 commits
  8. 30 Aug, 2006 1 commit
  9. 29 Aug, 2006 2 commits
    • Ian Lynagh's avatar
      Allow threading to be completely disabled with USETHREADS=0 · 33b3f651
      Ian Lynagh authored
      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.
      33b3f651
    • Ian Lynagh's avatar
      Clean .hp files · a67606ed
      Ian Lynagh authored
      a67606ed
  10. 22 Aug, 2006 1 commit
  11. 13 Aug, 2006 1 commit
  12. 20 Mar, 2006 2 commits
    • Simon Marlow's avatar
      fix for GHCi tests that raise exceptions or exit · 2dbdcc36
      Simon Marlow authored
      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.
      2dbdcc36
    • Simon Marlow's avatar
      sort the keys when outputting the summary · 0998d4fb
      Simon Marlow authored
      0998d4fb
  13. 16 Mar, 2006 2 commits
  14. 15 Mar, 2006 2 commits
  15. 18 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-18 16:31:10 by simonmar] · ff6b4956
      simonmar authored
      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.
      ff6b4956
  16. 26 Dec, 2005 1 commit
  17. 21 Oct, 2005 1 commit
  18. 23 May, 2005 1 commit
  19. 19 May, 2005 1 commit
  20. 11 Feb, 2005 1 commit
  21. 07 Feb, 2005 1 commit
  22. 04 Feb, 2005 1 commit
  23. 09 Nov, 2004 1 commit
    • ross's avatar
      [project @ 2004-11-09 13:49:08 by ross] · 7d1395dd
      ross authored
      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.
      7d1395dd
  24. 12 Oct, 2004 1 commit
  25. 09 Sep, 2004 1 commit
  26. 06 Sep, 2004 2 commits
  27. 01 Sep, 2004 1 commit
  28. 19 Jul, 2004 1 commit
    • igloo's avatar
      [project @ 2004-07-19 22:11:45 by igloo] · 805e7047
      igloo authored
      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.
      805e7047
  29. 16 Mar, 2004 1 commit
  30. 17 Feb, 2004 1 commit
  31. 19 Aug, 2003 1 commit
    • krc's avatar
      [project @ 2003-08-19 21:51:53 by krc] · a27b1e51
      krc authored
      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.
      a27b1e51
  32. 25 Jul, 2003 1 commit