1. 19 Jul, 2007 1 commit
  2. 27 Jun, 2007 2 commits
  3. 10 May, 2007 1 commit
  4. 16 Apr, 2007 1 commit
  5. 11 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Rationalise GhcMode, HscTarget and GhcLink · 3c22606b
      Simon Marlow authored
      This patch cleans up the GHC API, and adds some functionality: we can
      now compile to object code inside GHCi.
      
      Previously we had:
      
        data GhcMode
          = BatchCompile
          | Interactive
          | OneShot
          | JustTypecheck
          | MkDepend
        
        data HscTarget
          = HscC
          | HscAsm
          | HscJava
          | HscInterpreted
          | HscNothing
      
      There was redundancy here; if GhcMode is Interactive, then only
      HscInterpreted makes sense, and JustTypecheck required HscNothing.
      Now we have:
      
        data GhcMode
          = CompManager       -- ^ --make, GHCi, etc.
          | OneShot           -- ^ ghc -c Foo.hs
          | MkDepend          -- ^ ghc -M, see Finder for why we need this
      
      and HscTarget remains as before.
      
      Previously GhcLink looked like this:
      
        data GhcLink = NoLink | StaticLink
      
      Now we have:
      
        data GhcLink = NoLink | LinkBinary | LinkInMemory
      
      The idea being that you can have an HscTarget of HscAsm (for example)
      and still link in memory.
      
      There are two new flags:
      
        -fobject-code selects object code as the target (selects
                      either -fasm or -fvia-C, whichever is the default)
                      This can be usd with ':set' in GHCi, or on the command line.
      
        -fbyte-code   sets byte-code as the target.  Only works in GHCi.
                      One day maybe this could save the byte code in a file
                      when used outside GHCi.
      
        (names chosen for consistency with -fno-code).
      
      Changes to the GHC API: newSession no longer takes the GhcMode
      argument.  The GhcMode defaults to CompManager, which is usually what
      you want.  To do JustTypecheck now, just set hscTarget to HscNothing.
      3c22606b
  6. 08 Mar, 2007 1 commit
  7. 01 Mar, 2007 1 commit
  8. 15 Feb, 2007 1 commit
    • Simon Marlow's avatar
      When the pipeline just copies the file, prepend a LINE pragma · cf411c9a
      Simon Marlow authored
      For example, "ghc -E Foo.hs -o Foo.bar" just copies Foo.hs to
      Foo.bar.  This patch adds a LINE pragma to the beginning of Foo.bar so
      that further processing can track the location of the original file.
      
      The motiviation for this is bug #1044.  When generating Haddock docs,
      we preprocess the .hs to a .raw-hs, sometimes this doesn't involve any
      actual preprocessing and in those cases we lose track of the original
      filename.
      cf411c9a
  9. 15 Jan, 2007 1 commit
  10. 19 Oct, 2006 1 commit
  11. 11 Oct, 2006 1 commit
  12. 27 Jul, 2006 1 commit
  13. 27 Sep, 2006 1 commit
  14. 19 Sep, 2006 1 commit
    • Simon Marlow's avatar
      Packages cleanup, and allow new packages to be loaded with :set again · ee565d46
      Simon Marlow authored
      This cleans up the package subsystem a little.  There are some
      changes to the GHC API as a result.
      
        - GHC.init and GHC.initFromArgs are no longer necessary.
      
        - GHC.newSession takes the root of the GHC tree as an argument
          (previously passed to GHC.init).
      
        - You *must* do GHC.setSessionDynFlags after GHC.newSession,
          this is what loads the package database.
      
        - Several global vars removed from SysTools
      
        - The :set command in GHCi can now cause new packages to be loaded,
          or can hide/ignore existing packages.
      ee565d46
  15. 25 Aug, 2006 1 commit
    • rl@cse.unsw.edu.au's avatar
      Make sure GCC uses the Sparc V9 instruction set · 1777f480
      rl@cse.unsw.edu.au authored
      We only support Sparc V9 and better as V8 lacks an atomic CAS instruction
      which we need for SMP. This means that we have to pass -mcpu=v9 to GCC when
      compiling and assembling. Hardcoding the flag is hackish but seems to be
      our best bet at the moment. It can still be overridden by the user as GCC
      picks the best -mcpu flag regardless of the ordering.
      1777f480
  16. 09 Jul, 2006 1 commit
  17. 25 Jul, 2006 1 commit
    • Simon Marlow's avatar
      Generalise Package Support · 61d2625a
      Simon Marlow authored
      This patch pushes through one fundamental change: a module is now
      identified by the pair of its package and module name, whereas
      previously it was identified by its module name alone.  This means
      that now a program can contain multiple modules with the same name, as
      long as they belong to different packages.
      
      This is a language change - the Haskell report says nothing about
      packages, but it is now necessary to understand packages in order to
      understand GHC's module system.  For example, a type T from module M
      in package P is different from a type T from module M in package Q.
      Previously this wasn't an issue because there could only be a single
      module M in the program.
      
      The "module restriction" on combining packages has therefore been
      lifted, and a program can contain multiple versions of the same
      package.
      
      Note that none of the proposed syntax changes have yet been
      implemented, but the architecture is geared towards supporting import
      declarations qualified by package name, and that is probably the next
      step.
      
      It is now necessary to specify the package name when compiling a
      package, using the -package-name flag (which has been un-deprecated).
      Fortunately Cabal still uses -package-name.
      
      Certain packages are "wired in".  Currently the wired-in packages are:
      base, haskell98, template-haskell and rts, and are always referred to
      by these versionless names.  Other packages are referred to with full
      package IDs (eg. "network-1.0").  This is because the compiler needs
      to refer to entities in the wired-in packages, and we didn't want to
      bake the version of these packages into the comiler.  It's conceivable
      that someone might want to upgrade the base package independently of
      GHC.
      
      Internal changes:
      
        - There are two module-related types:
      
              ModuleName      just a FastString, the name of a module
              Module          a pair of a PackageId and ModuleName
      
          A mapping from ModuleName can be a UniqFM, but a mapping from Module
          must be a FiniteMap (we provide it as ModuleEnv).
      
        - The "HomeModules" type that was passed around the compiler is now
          gone, replaced in most cases by the current package name which is
          contained in DynFlags.  We can tell whether a Module comes from the
          current package by comparing its package name against the current
          package.
      
        - While I was here, I changed PrintUnqual to be a little more useful:
          it now returns the ModuleName that the identifier should be qualified
          with according to the current scope, rather than its original
          module.  Also, PrintUnqual tells whether to qualify module names with
          package names (currently unused).
      
      Docs to follow.
      61d2625a
  18. 11 Jun, 2006 1 commit
  19. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  20. 06 Apr, 2006 1 commit
  21. 18 Mar, 2006 2 commits
    • David Himmelstrup's avatar
      -fno-code shouldn't be a mode. · 851154f0
      David Himmelstrup authored
      I've removed -fno-code from Main to make it work
      equally well with --make and -c.
      I've also allowed it not to write hi files unless
      -fwrite-iface is given.
      851154f0
    • David Himmelstrup's avatar
      -fno-code shouldn't be a mode. · 4a3042fc
      David Himmelstrup authored
      I've removed -fno-code from Main to make it work
      equally well with --make and -c.
      I've also allowed it not to write hi files unless
      -fwrite-iface is given.
      4a3042fc
  22. 12 Mar, 2006 1 commit
  23. 10 Mar, 2006 1 commit
    • David Himmelstrup's avatar
      Parse OPTIONS properly and cache the result. · d700953c
      David Himmelstrup authored
      Use the lexer to parse OPTIONS, LANGUAGE and INCLUDE pragmas.
      This gives us greater flexibility and far better error
      messages. However, I had to make a few quirks:
        * The token parser is written manually since Happy doesn't
          like lexer errors (we need to extract options before the
          buffer is passed through 'cpp'). Still better than
          manually parsing a String, though.
        * The StringBuffer API has been extended so files can be
          read in blocks.
      I also made a new field in ModSummary called ms_hspp_opts
      which stores the updated DynFlags. Oh, and I took the liberty
      of moving 'getImports' into HeaderInfo together with
      'getOptions'.
      d700953c
  24. 07 Mar, 2006 1 commit
    • David Himmelstrup's avatar
      More work thrown at HscMain. · d1545b69
      David Himmelstrup authored
      MkIface.writeIfaceFile doesn't check GhcMode anymore. All it does
      is what the name say: write an interface to disk.
      I've refactored HscMain so the logic is easier to manage. That means
      we can avoid running the simplifier when typechecking (: And best of
      all, HscMain doesn't use GhcMode at all, anymore!
      
      The new HscMain intro looks like this:
      
      It's the task of the compilation proper to compile Haskell, hs-boot and
      core files to either byte-code, hard-code (C, asm, Java, ect) or to
      nothing at all (the module is still parsed and type-checked. This
      feature is mostly used by IDE's and the likes).
      Compilation can happen in either 'one-shot', 'batch', 'nothing',
      or 'interactive' mode. 'One-shot' mode targets hard-code, 'batch' mode
      targets hard-code, 'nothing' mode targets nothing and 'interactive' mode
      targets byte-code.
      The modes are kept separate because of their different types and meanings.
      In 'one-shot' mode, we're only compiling a single file and can therefore
      discard the new ModIface and ModDetails. This is also the reason it only
      targets hard-code; compiling to byte-code or nothing doesn't make sense
      when we discard the result.
      'Batch' mode is like 'one-shot' except that we keep the resulting ModIface
      and ModDetails. 'Batch' mode doesn't target byte-code since that require
      us to return the newly compiled byte-code.
      'Nothing' mode has exactly the same type as 'batch' mode but they're still
      kept separate. This is because compiling to nothing is fairly special: We
      don't output any interface files, we don't run the simplifier and we don't
      generate any code.
      'Interactive' mode is similar to 'batch' mode except that we return the
      compiled byte-code together with the ModIface and ModDetails.
      d1545b69
  25. 04 Mar, 2006 3 commits
  26. 02 Mar, 2006 1 commit
    • Simon Marlow's avatar
      Make -split-objs work with --make · ec968a32
      Simon Marlow authored
      This turned out to be a lot easier than I thought.  Just moving a few
      bits of -split-objs support from the build system into the compiler
      was enough.  The only thing that Cabal needs to do in order to support
      -split-objs now is to pass the names of the split objects rather than
      the monolithic ones to 'ar'.
      ec968a32
  27. 24 Feb, 2006 1 commit
  28. 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
  29. 23 Nov, 2005 1 commit
  30. 09 Nov, 2005 1 commit
  31. 08 Nov, 2005 2 commits
    • simonmar's avatar
      [project @ 2005-11-08 12:56:04 by simonmar] · 03341842
      simonmar authored
      gcc's -fstrict-aliasing is biting us when we use the stack to store
      different types of objects.  For example:
      
        *((StgDouble*)((W_)Sp-8)) = *((StgDouble*)((W_)Sp+8));
        Sp[1] = (W_)&s1Cx_info;
      
      gcc feels free to reorder these two lines, because they refer to
      differently typed objects, even though the assignment to Sp[1] clearly
      aliases the read from the same location.
      
      Trying to fix this by accessing locations using union types might be
      possible, but I took the sledgehammer approach of
      -fno-strict-aliasing.  This is justified to a certain extent because
      our generated C code is derived from a very weakly-typed internal
      language (C--).
      03341842
    • simonmar's avatar
      [project @ 2005-11-08 12:31:36 by simonmar] · 27249023
      simonmar authored
      unless I'm mistaken, only x86 needs -ffloat-store.  x86_64 certainly
      doesn't need it, because it uses SSE2 with the correct-sized floating
      point registers and doesn't store temporary results with more
      precision than results in memory.
      27249023
  32. 30 Oct, 2005 1 commit
    • krasimir's avatar
      [project @ 2005-10-30 19:12:31 by krasimir] · 6e64c691
      krasimir authored
      Change the way in which the .exe suffix to the output file is added. The reason
      is that "-o main" will generate main.exe on Windows while the doesFileExists "main"
      in DriverPipeline.link will return False.
      6e64c691
  33. 28 Oct, 2005 2 commits
    • simonmar's avatar
      [project @ 2005-10-28 15:22:39 by simonmar] · f2e730f3
      simonmar authored
      Add -stubdir option to control location of generated stub files.  Also
      do some clean up while I'm here - remove hscStubCOut/hscStubHOut from
      DynFlags, and add
      
        mkStubPaths :: DynFlags -> Module -> ModLocation -> (FilePath,FilePath)
      
      to Finder.  (this seemed better than caching the stub paths in every
      ModLocation, because they are rarely needed and only present in home
      modules, and are easily calculated from other available information).
      
      -stubdir behaves in exactly the same way as -odir and -hidir.
      f2e730f3
    • simonmar's avatar
      [project @ 2005-10-28 11:29:19 by simonmar] · d8afca91
      simonmar authored
      Fix double "Linking ..." message, and mention the name of the
      executable in the message.
      d8afca91
  34. 25 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-25 12:48:35 by simonmar] · 78b72ed1
      simonmar authored
      Two changes from Krasimir Angelov, which were required for Visual
      Haskell:
      
        - messaging cleanup throughout the compiler.  DynFlags has a new
          field:
      
          log_action :: Severity -> SrcSpan -> PprStyle -> Message -> IO ()
      
          this action is invoked for every message generated by the
          compiler.  This means a client of the GHC API can direct messages to
          any destination, or collect them up in an IORef for later
          perusal.
      
          This replaces previous hacks to redirect messages in the GHC API
          (hence some changes to function types in GHC.hs).
      
        - The JustTypecheck mode of GHC now does what it says.  It doesn't
          run any of the compiler passes beyond the typechecker for each module,
          but does generate the ModIface in order that further modules can be
          typechecked.
      
      And one change from me:
      
        - implement the LANGUAGE pragma, finally
      78b72ed1