1. 21 Sep, 2015 1 commit
    • Edward Z. Yang's avatar
      Unify hsig and hs-boot; add preliminary "hs-boot" merging. · 06d46b1e
      Edward Z. Yang authored
      This patch drops the file level distinction between hs-boot and hsig;
      we figure out which one we are compiling based on whether or not there
      is a corresponding hs file lying around.
      
      To make the "import A" syntax continue to work for bare hs-boot
      files, we also introduce hs-boot merging, which takes an A.hi-boot
      and converts it to an A.hi when there is no A.hs file in scope.
      This will be generalized in Backpack to merge multiple A.hi files together;
      which means we can jettison the "load multiple interface files" functionality.
      
      This works automatically for --make, but for one-shot compilation
      we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
      from a local A.hi-boot file; Backpack will extend this mechanism further.
      
      Has Haddock submodule update to deal with change in msHsFilePath behavior.
      
          - This commit drops support for the hsig extension. Can
            we support it?  It's annoying because the finder code is
            written with the assumption that where there's an hs-boot
            file, there's always an hs file too.  To support hsig, you'd
            have to probe two locations.  Easier to just not support it.
      
          - #10333 affects us, modifying an hs-boot still doesn't trigger
            recomp.
      
          - See compiler/main/Finder.hs: this diff is very skeevy, but
            it seems to work.
      
          - This code cunningly doesn't drop hs-boot files from the
            "drop hs-boot files" module graph, if they don't have a
            corresponding hs file.  I have no idea if this actually is useful.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, spinda
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1098
      06d46b1e
  2. 22 Jul, 2015 1 commit
  3. 01 Apr, 2015 1 commit
    • thomie's avatar
      Change which files --make thinks are 'Haskellish' (#10220) · 7cec6c7b
      thomie authored
      `.hspp` and `.hscpp` are haskell files that have already been preprocessed.
      
      Treat `.hspp` and `.hscpp` as Haskellish sources again, as they were before
      commit a10e1990. This way, ghc --make will load their imports.
      
      Make sure that `.cmm` and `.cmmcpp` are still not treated as Haskellish,
      by moving them out of `haskell_src_suffixes` (but still keeping them in
      haskellish_suffixes, though I'm not sure what the purpose of that group
      is).
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D778
      7cec6c7b
  4. 31 Mar, 2015 2 commits
  5. 28 Mar, 2015 1 commit
  6. 27 Mar, 2015 1 commit
    • thomie's avatar
      Rename driver phases C(obj)cpp to C(obj)cplusplus · abde5da4
      thomie authored
      Before:
      Cpp     = Pre-process C
      Ccpp    = Compile C++
      Cobjcpp = Compile Objective-C++
      CmmCpp  = Pre-process Cmm
      
      Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and
      `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for
      `pre-processing` throughout the compiler.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D756
      abde5da4
  7. 24 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Implementation of hsig (module signatures), per #9252 · aa479953
      Edward Z. Yang authored
      Summary:
      Module signatures, like hs-boot files, are Haskell modules which omit
      value definitions and contain only signatures.  This patchset implements
      one particular aspect of module signature, namely compiling them against
      a concrete implementation.  It works like this: when we compile an hsig
      file, we must be told (via the -sig-of flag) what module this signature
      is implementing.  The signature is compiled into an interface file which
      reexports precisely the entities mentioned in the signature file.  We also
      verify that the interface is compatible with the implementation.
      
      This feature is useful in a few situations:
      
          1. Like explicit import lists, signatures can be used to reduce
          sensitivity to upstream changes.  However, a signature can be defined
          once and then reused by many modules.
      
          2. Signatures can be used to quickly check if a new upstream version
          is compatible, by typechecking just the signatures and not the actual
          modules.
      
          3. A signature can be used to mediate separate modular development,
          where the signature is used as a placeholder for functionality which
          is loaded in later.  (This is only half useful at the moment, since
          typechecking against signatures without implementations is not implemented
          in this patchset.)
      
      Unlike hs-boot files, hsig files impose no performance overhead.
      
      This patchset punts on the type class instances (and type families) problem:
      instances simply leak from the implementation to the signature.  You can
      explicitly specify what instances you expect to have, and those will be checked,
      but you may get more instances than you asked for.  Our eventual plan is
      to allow hiding instances, but to consider all transitively reachable instances
      when considering overlap and soundness.
      
      ToDo: signature merging: when a module is provided by multiple signatures
      for the same base implementation, we should not consider this ambiguous.
      
      ToDo: at the moment, signatures do not constitute use-sites, so if you
      write a signature for a deprecated function, you won't get a warning
      when you compile the signature.
      
      Future work: The ability to feed in shaping information so that we can take
      advantage of more type equalities than might be immediately evident.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate and new tests
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D130
      
      GHC Trac Issues: #9252
      aa479953
  8. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  9. 03 May, 2014 1 commit
  10. 08 Apr, 2014 1 commit
  11. 17 Feb, 2014 1 commit
    • Austin Seipp's avatar
      Fix #8770 · dc080915
      Austin Seipp authored
      As usual, Mac OS X is extremely annoying (or the software is, anyway),
      because not only does it load dynamic libraries with the .dylib
      extension, but also the .so extension. For whatever reason. At least
      it's easy to fix.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      dc080915
  12. 11 Jan, 2013 1 commit
  13. 28 Aug, 2012 1 commit
  14. 22 Nov, 2011 2 commits
  15. 04 Nov, 2011 1 commit
  16. 15 Sep, 2011 1 commit
  17. 06 Aug, 2011 1 commit
  18. 04 May, 2011 1 commit
    • dterei's avatar
      LLVM: Support LLVM 2.9 (#5103) · 50e0db45
      dterei authored
      Instead of using the GNU As subsection feature on Linux/Windows
      for TNTC we now use the LLVM Mangler on all platforms.
      50e0db45
  19. 05 Apr, 2011 1 commit
    • Simon Marlow's avatar
      Merge _stub.o files into the main .o file (Fixes #3687 and #706) · 7b0ff179
      Simon Marlow authored
      Now GHC still generates the _stub.c files, but the object file is
      automatically merged into the main .o file for a module.  This means
      that build systems (including GHC's own) no longer need to worry about
      looking for _stub.o files and including them when linking.
      
      I had to do lots of refactoring in DriverPipeline to make this work;
      now there's a monad to carry around all the information, and
      everything is a lot tidier.
      
      The _stub.c is now created as a temporary file and removed after
      compilation (unless the -keep-tmp-files flag is on).
      7b0ff179
  20. 04 Apr, 2011 2 commits
  21. 05 Aug, 2010 1 commit
  22. 29 Jul, 2010 1 commit
  23. 13 Jul, 2010 1 commit
  24. 22 Jun, 2010 1 commit
  25. 15 Jun, 2010 1 commit
  26. 12 Jun, 2010 1 commit
  27. 23 Apr, 2008 1 commit
  28. 25 Mar, 2008 1 commit
  29. 12 Jan, 2008 1 commit
  30. 21 Sep, 2007 1 commit
  31. 04 Sep, 2007 1 commit
  32. 03 Sep, 2007 1 commit
  33. 01 Sep, 2007 1 commit
  34. 04 Oct, 2006 1 commit
  35. 27 Jul, 2006 1 commit
  36. 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
  37. 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