1. 24 Oct, 2003 1 commit
  2. 23 Oct, 2003 1 commit
  3. 20 Oct, 2003 1 commit
  4. 13 Oct, 2003 1 commit
  5. 06 Oct, 2003 2 commits
  6. 01 Oct, 2003 1 commit
  7. 30 Sep, 2003 2 commits
  8. 26 Sep, 2003 1 commit
  9. 24 Sep, 2003 6 commits
  10. 23 Sep, 2003 2 commits
  11. 20 Sep, 2003 1 commit
  12. 11 Sep, 2003 4 commits
  13. 10 Sep, 2003 3 commits
  14. 08 Sep, 2003 3 commits
    • simonmar's avatar
      [project @ 2003-09-08 12:59:05 by simonmar] · cf19aa1d
      simonmar authored
      Add a couple of signal-handling tests I had lying around.
    • simonmar's avatar
      [project @ 2003-09-08 12:53:47 by simonmar] · 3a558d26
      simonmar authored
      Update expected output
    • simonmar's avatar
      [project @ 2003-09-08 11:52:27 by simonmar] · 70676336
      simonmar authored
      Replace the handwritten lexer with one generated by Alex.
        - Faster than the previous lexer (about 10% of total parse time,
          depending on the token mix).
        - More correct than the previous lexer: a couple of minor wibbles
          in the syntax were fixed.
        - Completely accurate source spans for each token are now collected.
          This information isn't used yet, but it will be used to give much
          more accurate error messages in the future.
        - SrcLoc now contains a column field as well as a line number,
          although this is currently ignored when printing out SrcLocs.
        - StringBuffer is now based on a ByteArray# rather than a Ptr, which
          means that StringBuffers are now garbage collected.  Previously
          StringBuffers were hardly ever released, so a GHCi session would
          leak space as more source files were loaded in.
        - Code size reduction: Lexer.x is about the same size as the old
          Lex.lhs, but StringBuffer.lhs is significantly shorter and
          simpler.  Sadly I wasn't able to get rid of parser/Ctypes.hs
  15. 27 Aug, 2003 1 commit
  16. 20 Aug, 2003 2 commits
  17. 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
      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.
  18. 14 Aug, 2003 1 commit
  19. 04 Aug, 2003 2 commits
  20. 31 Jul, 2003 2 commits
  21. 29 Jul, 2003 2 commits