1. 09 Mar, 2017 1 commit
    • bitonic's avatar
      Allow compilation of C/C++/ObjC/ObjC++ files with module from TH · 0fac488c
      bitonic authored
      The main goal is to easily allow the inline-c project (and
      similar projects such as inline-java) to emit C/C++ files to
      be compiled and linked with the current module.
      
      Moreover, `addCStub` is removed, since it's quite fragile. Most
      notably, the C stubs end up in the file generated by
      `CodeOutput.outputForeignStubs`, which is tuned towards
      generating a file for stubs coming from `capi` and Haskell-to-C
      exports.
      
      Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari
      
      Reviewed By: dfeuer, bgamari
      
      Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes
      
      Differential Revision: https://phabricator.haskell.org/D3280
      0fac488c
  2. 15 Dec, 2016 1 commit
  3. 08 Oct, 2016 1 commit
  4. 16 May, 2016 1 commit
    • Ben Gamari's avatar
      Move Extension type to ghc-boot-th · eed820b6
      Ben Gamari authored
      This creates a new package, `ghc-boot-th`, to contain the `Extension`
      type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
      the transitive dependency set of the `template-haskell` package remains
      minimal.
      
      The `GHC.LanguageExtensions.Type` module is also re-exported by
      `ghc-boot`, which provides an orphan `binary` instance as well.
      
      Test Plan: Validate
      
      Reviewers: goldfire, thomie, hvr, austin
      
      Reviewed By: thomie
      
      Subscribers: RyanGlScott, thomie, erikd, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2224
      eed820b6
  5. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  6. 19 Dec, 2015 1 commit
  7. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  8. 16 Dec, 2015 1 commit
  9. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
  10. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      `bin-package-db`).
      
      Reviewed By: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1313
      
      GHC Trac Issues: #10796
      d2f9972a
  11. 29 Aug, 2014 2 commits
    • Duncan Coutts's avatar
      Move Cabal Binary instances from bin-package-db to ghc-pkg itself · 0af7d0c1
      Duncan Coutts authored
      The ghc-pkg program of course still depends on Cabal, it's just the
      bin-package-db library (shared between ghc and ghc-pkg) that does not.
      0af7d0c1
    • Duncan Coutts's avatar
      Introduce new file format for the package database binary cache · 8d7a1dcd
      Duncan Coutts authored
      The purpose of the new format is to make it possible for the compiler
      to not depend on the Cabal library. The new cache file format contains
      more or less the same information duplicated in two different sections
      using different representations.
      
      One section is basically the same as what the package db contains now,
      a list of packages using the types defined in the Cabal library. This
      section is read back by ghc-pkg, and used for things like ghc-pkg dump
      which have to produce output using the Cabal InstalledPackageInfo text
      representation.
      
      The other section is a ghc-local type which contains a subset of the
      information from the Cabal InstalledPackageInfo -- just the bits that
      the compiler cares about.
      
      The trick is that the compiler can read this second section without
      needing to know the representation (or types) of the first part. The
      ghc-pkg tool knows about both representations and writes both.
      
      This patch introduces the new cache file format but does not yet use it
      properly. More patches to follow. (As of this patch, the compiler reads
      the part intended for ghc-pkg so it still depends on Cabal and the
      ghc-local package type is not yet fully defined.)
      8d7a1dcd
  12. 21 Jul, 2014 1 commit
  13. 20 Jul, 2014 1 commit
  14. 18 Jul, 2014 1 commit
  15. 15 May, 2014 1 commit
  16. 14 May, 2014 1 commit
  17. 16 Apr, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Update Cabal submodule to tip of v1.20 branch · 8992d526
      Herbert Valerio Riedel authored
      This corresponds to the RC of the soon-to-be Cabal 1.20 release
      
      One noteworthy change is the removal of the `--with-ranlib` flag
      requiring a small adaptation in the GHC build system.
      
      Moreover two new licences were added, MPL and BSD2.
      
      Due to https://github.com/haskell/cabal/issues/1622
      
       Cabal-1.20 now
      allows to strip libraries as well, this doesn't work well with
      `ghc-cabal copy` being fed a `":"` strip-command argument which was
      simply ignored in the past. The current code tries to retain this
      semantics as backward compat. However, this needs more investigation as
      I'm not sure if/why the `test_bindist` step doesn't want the libraries
      to be stripped on installation.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      8992d526
  18. 11 Sep, 2013 1 commit
  19. 26 Aug, 2013 1 commit
  20. 22 Aug, 2013 1 commit
  21. 18 Mar, 2013 1 commit
  22. 01 Mar, 2013 1 commit
  23. 19 Jul, 2012 1 commit
  24. 20 Jan, 2012 1 commit
  25. 08 Jul, 2011 1 commit
  26. 12 Oct, 2010 1 commit
  27. 23 Sep, 2010 1 commit
  28. 29 Nov, 2009 2 commits
    • Ian Lynagh's avatar
      Update dependencies · e5e9ef45
      Ian Lynagh authored
      e5e9ef45
    • Ian Lynagh's avatar
      Give more informative error messages · f9460db8
      Ian Lynagh authored
      We used to just get
          ghc: panic! (the 'impossible' happened)
            (GHC version 6.13.20091128 for x86_64-unknown-linux):
              too few bytes. Failed reading at byte position 32753
      with no indication of what was being parsed.
      f9460db8
  29. 06 Oct, 2009 1 commit
  30. 11 Sep, 2009 1 commit
  31. 10 Sep, 2009 1 commit
    • Simon Marlow's avatar
      Change the representation of the package database · 930421d4
      Simon Marlow authored
       - the package DB is a directory containing one file per package
         instance (#723)
      
       - there is a binary cache of the database (#593, #2089)
      
       - the binary package is now a boot package
      
       - there is a new package, bin-package-db, containing the Binary
         instance of InstalledPackageInfo for the binary cache.
      
      Also included in this patch
      
       - Use colour in 'ghc-pkg list' to indicate broken or hidden packages
        
         Broken packages are red, hidden packages are 
        
         Colour support comes from the terminfo package, and is only used when
          - not --simple-output
          - stdout is a TTY
          - the terminal type has colour capability
      
       - Fix the bug that 'ghc-pkg list --user' shows everything as broken
      930421d4