1. 07 Nov, 2014 1 commit
    • rodlogic's avatar
      small parser/lexer cleanup · 37d64a51
      rodlogic authored
      Summary:
      The last three '#define ...' macros were removed from Parser.y.pp and this file was renamed to Parser.y.
      This basically got rid of a CPP step in the build.
      
      Also converted two modules in compiler/parser/ from .lhs to .hs.
      
      Test Plan: Does it build? Yes, I performed a full build here and things are looking good.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: adamse, thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D411
      37d64a51
  2. 05 Oct, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `MIN_VERSION_GLASGOW_HASKELL()` macro · 3549c952
      Herbert Valerio Riedel authored
      This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
      allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
      would result in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
        #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
      
      while GHC 7.10.3 results in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
      
      and finally GHC 7.9.20141009 results in
      
        #define __GLASGOW_HASKELL__             709
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
      
      As it's error-prone to properly express CPP conditionals for testing GHC
      multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
      provided (also via the new CPP include file `ghcversion.h`)
      
      Finally, in order to make it easier to define the new CPP macro
      `MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
      `include/ghcversion.h` is used for the new CPP definitions.
      
      Reviewed By: ekmett, austin, #ghc
      
      Differential Revision: https://phabricator.haskell.org/D66
      3549c952
  3. 24 Sep, 2014 1 commit
    • Edward Z. Yang's avatar
      Update Cabal submodule & ghc-pkg to use new module re-export types · 4b648be1
      Edward Z. Yang authored
      Summary:
      The main change is that Cabal changed the representation of module
      re-exports to distinguish reexports in source .cabal files versus
      re-exports in installed package registraion files.
      
      Cabal now also does the resolution of re-exports to specific installed
      packages itself, so ghc-pkg no longer has to do this. This is a cleaner
      design overall because re-export resolution can fail so it is better to
      do it during package configuration rather than package registration.
      It also simplifies the re-export representation that ghc-pkg has to use.
      
      Add extra ghc-pkg sanity check for module re-exports and duplicates
      
      For re-exports, check that the defining package exists and that it
      exposes the defining module (or for self-rexport exposed or hidden
      modules). Also check that the defining package is actually a direct
      or indirect dependency of the package doing the re-exporting.
      
      Also add a check for duplicate modules in a package, including
      re-exported modules.
      
      Test Plan:
      So far the sanity checks are totally untested. Should add some test
      case to make sure the sanity checks do catch things correctly, and
      don't ban legal things.
      
      Reviewers: austin, duncan
      
      Subscribers: angerman, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D183
      
      GHC Trac Issues:
      4b648be1
  4. 29 Aug, 2014 1 commit
  5. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  6. 28 Jul, 2014 1 commit
  7. 29 Jun, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add BUILD_DPH variable to GHC build-system · 88d85aa6
      Herbert Valerio Riedel authored
      Now that the `libraries/dph` submodule is checked out always we need
      a different way to disable building DPH to save compile-time while
      developing GHC.
      
      This commit adds a new YES/NO Make variable `BUILD_DPH` that can be used
      inside mk/build.mk to control whether to build libraries/dph or not.
      The default setting is `BUILD_DPH=YES` (via `mk/config.mk.in`).
      
      This also changes `validate`'s flag `--no-dph` to explicitly disable DPH
      for the current validation run.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      
      Test Plan: successful validates with `--fast --no-dph`
      
      Differential Revision: https://phabricator.haskell.org/D31
      88d85aa6
  8. 09 Jun, 2014 1 commit
  9. 03 May, 2014 1 commit
  10. 22 Apr, 2014 1 commit
  11. 31 Mar, 2014 1 commit
  12. 26 Feb, 2014 1 commit
  13. 20 Feb, 2014 1 commit
  14. 09 Feb, 2014 2 commits
  15. 31 Jan, 2014 2 commits
  16. 28 Jan, 2014 1 commit
  17. 17 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Fix #8675 · e4a4abae
      Austin Seipp authored
      Haddock no longer has a generated parser, so we don't need it in the
      sdist and we certainly don't want to check for it in the ./configure
      script (as that would be bogus.)
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      e4a4abae
  18. 25 Oct, 2013 1 commit
  19. 01 Oct, 2013 1 commit
  20. 15 Sep, 2013 1 commit
  21. 15 Aug, 2013 1 commit
    • thoughtpolice's avatar
      Don't delete HsTimeConfig.h.in during distclean. · 94c35ddf
      thoughtpolice authored
      sdist preps the tree via distclean before anything else, which caused
      HsTimeConfig.h.in under 'time' to be deleted - even though it should be
      included in the resulting tarball for ./configure.
      
      The correct target is 'maintainer-clean'.
      
      I'm guessing the nightlies didn't complain because they run ./boot,
      forcing regeneration. NixOS's Hydra does not, though.
      
      Thanks to Peter Simons and Andres Löh for pointing this out.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      94c35ddf
  22. 14 Aug, 2013 1 commit
  23. 30 Jul, 2013 1 commit
  24. 03 Jul, 2013 1 commit
    • ian@well-typed.com's avatar
      Change the ranlib detection · c548fec4
      ian@well-typed.com authored
      On Windows, the ranlib in the path may not be the right ranlib (it may
      be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
      Therefore we can't leave it up to libffi to detect the right ranlib, but
      need to tell it which ranlib to use. This means that we need to find
      ranlib even if we don't actually need it ourselves.
      c548fec4
  25. 22 Jun, 2013 1 commit
  26. 14 Jun, 2013 1 commit
  27. 09 Jun, 2013 4 commits
  28. 25 May, 2013 1 commit
  29. 19 May, 2013 1 commit
  30. 14 May, 2013 2 commits
  31. 12 May, 2013 2 commits
    • Ian Lynagh's avatar
      More work towards dynamic programs on Windows · b35a6ce0
      Ian Lynagh authored
      Dynamic GHC is now working in-place, but pathologically slow due
      to the DLL split.
      
      (GHC assumes that all intra-package calls are in the same DLL, but that
      isn't true when we split the GHC package into 2 DLLs. That means that
      GHC's startup time is around 22 seconds, as it is doing run-time
      linking).
      
      Also, ghci isn't actually working yet:
      
      $ inplace/bin/ghc-stage2 --interactive
      GHCi, version 7.7.20130512: http://www.haskell.org/ghc/  :? for help
      Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
      HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL)
      ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
      found.
      b35a6ce0
    • Ian Lynagh's avatar
      We actually need to use -threaded/-debug when linking /all/ DLLs · b2cae55f
      Ian Lynagh authored
      Not just base, integer-gmp and ghc-prim.
      b2cae55f
  32. 10 May, 2013 1 commit
  33. 09 May, 2013 1 commit
    • ian@well-typed.com's avatar
      Fix dynamically linked GHC on Windows · a5a52d79
      ian@well-typed.com authored
      This is a rather ugly hack to fix dynamically linked GHC on Windows.
      
      If GHC is linked with -threaded, then it links against libHSrts_thr.
      But if base is linked against libHSrts, then both end up getting
      loaded, and things go wrong. We therefore link the libraries that
      link against the RTS with the same RTS flags that we link GHC with.
      a5a52d79