1. 19 Jan, 2006 1 commit
  2. 11 Jan, 2006 1 commit
  3. 09 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-09 13:25:50 by simonmar] · 5d8f5e00
      simonmar authored
      Fix up to compile with GHC 5.04.x again.
      
      Also includes a fix for a memory error I discovered along the way:
      should fix the "scavenge_one" crash in the stage2 build of recent
      HEADs.
      5d8f5e00
  4. 06 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-06 16:30:17 by simonmar] · 9d7da331
      simonmar authored
      Add support for UTF-8 source files
      
      GHC finally has support for full Unicode in source files.  Source
      files are now assumed to be UTF-8 encoded, and the full range of
      Unicode characters can be used, with classifications recognised using
      the implementation from Data.Char.  This incedentally means that only
      the stage2 compiler will recognise Unicode in source files, because I
      was too lazy to port the unicode classifier code into libcompat.
      
      Additionally, the following synonyms for keywords are now recognised:
      
        forall symbol 	(U+2200)	forall
        right arrow   	(U+2192)	->
        left arrow   		(U+2190)	<-
        horizontal ellipsis 	(U+22EF)	..
      
      there are probably more things we could add here.
      
      This will break some source files if Latin-1 characters are being used.
      In most cases this should result in a UTF-8 decoding error.  Later on
      if we want to support more encodings (perhaps with a pragma to specify
      the encoding), I plan to do it by recoding into UTF-8 before parsing.
      
      Internally, there were some pretty big changes:
      
        - FastStrings are now stored in UTF-8
      
        - Z-encoding has been moved right to the back end.  Previously we
          used to Z-encode every identifier on the way in for simplicity,
          and only decode when we needed to show something to the user.
          Instead, we now keep every string in its UTF-8 encoding, and
          Z-encode right before printing it out.  To avoid Z-encoding the
          same string multiple times, the Z-encoding is cached inside the
          FastString the first time it is requested.
      
          This speeds up the compiler - I've measured some definite
          improvement in parsing at least, and I expect compilations overall
          to be faster too.  It also cleans up a lot of cruft from the
          OccName interface.  Z-encoding is nicely hidden inside the
          Outputable instance for Names & OccNames now.
      
        - StringBuffers are UTF-8 too, and are now represented as
          ForeignPtrs.
      
        - I've put together some test cases, not by any means exhaustive,
          but there are some interesting UTF-8 decoding error cases that
          aren't obvious.  Also, take a look at unicode001.hs for a demo.
      9d7da331
  5. 12 Dec, 2005 1 commit
  6. 16 Nov, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-11-16 17:45:38 by simonpj] · 491c85e7
      simonpj authored
      Better error reporting for newtypes with too many constructors,
      or too many fields.  Instead of yielding a parse error, we
      parse it like a data type declaration, and give a comprehensible
      error message later.
      
      A suggestion from Jan-Willem.
      491c85e7
  7. 16 Sep, 2005 2 commits
  8. 15 Sep, 2005 1 commit
  9. 14 Sep, 2005 1 commit
  10. 13 Sep, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-09-13 12:50:59 by simonmar] · 5971cecb
      simonmar authored
      Never use an installed Cabal package when building GHC (except when
      bootstrapping in stages 2 & 3).  This insulates us from changes the
      user may have made to their Cabal installation.
      5971cecb
  11. 25 Jul, 2005 1 commit
  12. 21 Jul, 2005 1 commit
  13. 08 Jul, 2005 1 commit
  14. 16 Jun, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-06-16 09:45:28 by simonmar] · 1957057d
      simonmar authored
      Move the boilerplate Makefile code for using libghccompat.a into a
      shared .mk file, lib/compat/compat.mk.  libghccompat.a is really a
      poor-mans package, but to make it a real package would mean dealing
      with variationg in the package support of different GHC versions, so
      this is easier for now.
      1957057d
  15. 10 May, 2005 1 commit
  16. 17 Apr, 2005 1 commit
  17. 07 Apr, 2005 1 commit
    • wolfgang's avatar
      [project @ 2005-04-07 05:27:16 by wolfgang] · d79c1cb2
      wolfgang authored
      Set the keepCAFs flag (required for GHCi with dynamic libraries) from an
      __attribute__((constructor)) function linked to stage 2 ghc if GhcBuildDylibs
      is set in mk/build.mk.
      
      The previous hack (setting it from addDLL) didn't work, because a few CAFs
      from libHSbase_dyn were evaluated before the Linker was first invoked by
      GHCi.
      
      MERGE TO STABLE
      d79c1cb2
  18. 05 Apr, 2005 1 commit
  19. 31 Mar, 2005 1 commit
  20. 24 Mar, 2005 2 commits
  21. 23 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-23 13:27:42 by simonmar] · c94111ff
      simonmar authored
      Build GHC package as part of stage 2, and install it.
      
      The following changes will affect those building the GHC package:
      
        - BuildPackageGHC=YES is no longer required in build.mk
        - You must build stage 2 in order to get package ghc.
        - 'make install-inplace-pkg' is not required (nor does it work)
        - -package ghc can be used with the local stage1 or stage2 compiler
          in the current build tree, and it will be available after a
          'make install'.
      
      The GHC package is no longer optional, but it doesn't add much to the
      build time.
      c94111ff
  22. 22 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-22 17:13:12 by simonmar] · 069370a5
      simonmar authored
      A start on the GHC API:
      
      Flesh out the GHC module so that it can replace CompManager.  Now, the
      clients that used CompManager consume the GHC API instead (namely
      Main, DriverMkDepend, and InteractiveUI).  Main is significantly
      cleaner as a result.
      
      The interface needs more work: in particular, getInfo returns results
      in the form of IfaceDecls but we want to use full HsSyn and
      Id/DataCon/Class across the boundary instead.
      
      The interfaces for inspecting loaded modules are not yet implemented.
      069370a5
  23. 21 Mar, 2005 1 commit
  24. 15 Mar, 2005 2 commits
  25. 10 Mar, 2005 1 commit
  26. 01 Mar, 2005 1 commit
  27. 25 Feb, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-02-25 13:06:31 by simonpj] · 8e67f550
      simonpj authored
      ---------------------------------------------
      Type signatures are no longer instantiated with skolem constants
      	---------------------------------------------
      
      	Merge to STABLE
      
      Consider
      
        p :: a
        q :: b
        (p,q,r) = (r,r,p)
      
      Here, 'a' and 'b' end up being the same, because they are both bound
      to the type for 'r', which is just a meta type variable.  So 'a' and 'b'
      can't be skolems.
      
      Sigh.  This commit goes back to an earlier way of doing things, by
      arranging that type signatures get instantiated with *meta* type
      variables; then at the end we must check that they have not been
      unified with types, nor with each other.
      
      This is a real bore.  I had to do quite a bit of related fiddling around
      to make error messages come out right.  Improved one or two.
      
      Also a small unrelated fix to make
      	:i (:+)
      print with parens in ghci.  Sorry this got mixed up in the same commit.
      8e67f550
  28. 23 Feb, 2005 1 commit
  29. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      
      Recall that:
      
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      
      Actual changes:
      
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
      
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
      
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
      
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
      
       - the compiler's Makefile now generates
           stage{1,2,3}/ghc_boot_platform.h
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
      
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
      
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
      
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
      
       - The Users's Guide is updated to mention *_HOST_* rather than
         *_TARGET_*.
      
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      
      Thanks to Wolfgang Thaller for pointing me in the right direction.
      153b9cb9
  30. 27 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-27 10:44:00 by simonpj] · 508a505e
      simonpj authored
      --------------------------------------------
                Replace hi-boot files with hs-boot files
        	--------------------------------------------
      
      This major commit completely re-organises the way that recursive modules
      are dealt with.
      
        * It should have NO EFFECT if you do not use recursive modules
      
        * It is a BREAKING CHANGE if you do
      
      ====== Warning: .hi-file format has changed, so if you are
      ======		updating into an existing HEAD build, you'll
      ======		need to make clean and re-make
      
      
      The details:  [documentation still to be done]
      
      * Recursive loops are now broken with Foo.hs-boot (or Foo.lhs-boot),
        not Foo.hi-boot
      
      * An hs-boot files is a proper source file.  It is compiled just like
        a regular Haskell source file:
      	ghc Foo.hs		generates Foo.hi, Foo.o
      	ghc Foo.hs-boot		generates Foo.hi-boot, Foo.o-boot
      
      * hs-boot files are precisely a subset of Haskell. In particular:
      	- they have the same import, export, and scoping rules
      	- errors (such as kind errors) in hs-boot files are checked
        You do *not* need to mention the "original" name of something in
        an hs-boot file, any more than you do in any other Haskell module.
      
      * The Foo.hi-boot file generated by compiling Foo.hs-boot is a machine-
        generated interface file, in precisely the same format as Foo.hi
      
      * When compiling Foo.hs, its exports are checked for compatibility with
        Foo.hi-boot (previously generated by compiling Foo.hs-boot)
      
      * The dependency analyser (ghc -M) knows about Foo.hs-boot files, and
        generates appropriate dependencies.  For regular source files it
        generates
      	Foo.o : Foo.hs
      	Foo.o : Baz.hi		-- Foo.hs imports Baz
      	Foo.o : Bog.hi-boot	-- Foo.hs source-imports Bog
      
        For a hs-boot file it generates similar dependencies
      	Bog.o-boot : Bog.hs-boot
      	Bog.o-boot : Nib.hi	-- Bog.hs-boto imports Nib
      
      * ghc -M is also enhanced to use the compilation manager dependency
        chasing, so that
      	ghc -M Main
        will usually do the job.  No need to enumerate all the source files.
      
      * The -c flag is no longer a "compiler mode". It simply means "omit the
        link step", and synonymous with -no-link.
      508a505e
  31. 26 Jan, 2005 1 commit
  32. 14 Jan, 2005 1 commit
  33. 12 Jan, 2005 3 commits
  34. 06 Jan, 2005 1 commit
  35. 01 Dec, 2004 1 commit