1. 06 Nov, 2016 1 commit
  2. 02 Nov, 2016 1 commit
    • Sylvain HENRY's avatar
      Uninstall signal handlers · 8a5960ad
      Sylvain HENRY authored
      GHC installs signal handlers in runGhc/runGhcT to handle ^C but it
      never uninstalls them.
      It can be an issue, especially when using GHC as a library.
      
      Test Plan: validate
      
      Reviewers: bgamari, erikd, austin, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2633
      
      GHC Trac Issues: #4162
      8a5960ad
  3. 24 May, 2016 1 commit
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
  4. 25 Mar, 2016 1 commit
  5. 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
  6. 03 Oct, 2015 1 commit
    • Tamar Christina's avatar
      Prevent GHC from silently dying when preprocessor is not found · b6f76b9a
      Tamar Christina authored
      The Windows preprocessor code calls `runInteractiveProcess` but does
      not check if an exception is thrown.
      `runInteractiveProcess` calls `CreateProcess` which when given a format
      the system loader does not know about
      will throw an exception. This is what makes #9399 fail.
      
      Ultimately we should not use any `CreateProcess` based calls but
      instead `ShellExecuteEx` as  this would allow
      us to run applications that the shell knows about instead of just the
      loader. More details on #365.
      
      This patch removes `PhaseFailed` and throws `ProgramError` instead.
      `PhaseFailed` was largely unneeded since it never gave
      very useful information aside from the `errorcode` which was almost
      always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
      thrown in their place wherever possible.
      
      Updates haddock submodule.
      
      Test Plan:
      `./validate` to make sure anything didn't break and
      `make TESTS="T365"` to test that an error is now properly thrown
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1256
      
      GHC Trac Issues: #365
      b6f76b9a
  7. 21 Aug, 2015 1 commit
    • thomie's avatar
      Refactor: delete most of the module FastTypes · 2f29ebbb
      thomie authored
      This reverses some of the work done in #1405, and goes back to the
      assumption that the bootstrap compiler understands GHC-haskell.
      
      In particular:
        * use MagicHash instead of _ILIT and _CLIT
        * pattern matching on I# if possible, instead of using iUnbox
          unnecessarily
        * use Int#/Char#/Addr# instead of the following type synonyms:
          - type FastInt   = Int#
          - type FastChar  = Char#
          - type FastPtr a = Addr#
        * inline the following functions:
          - iBox           = I#
          - cBox           = C#
          - fastChr        = chr#
          - fastOrd        = ord#
          - eqFastChar     = eqChar#
          - shiftLFastInt  = uncheckedIShiftL#
          - shiftR_FastInt = uncheckedIShiftRL#
          - shiftRLFastInt = uncheckedIShiftRL#
        * delete the following unused functions:
          - minFastInt
          - maxFastInt
          - uncheckedIShiftRA#
          - castFastPtr
          - panicDocFastInt and pprPanicFastInt
        * rename panicFastInt back to panic#
      
      These functions remain, since they actually do something:
        * iUnbox
        * bitAndFastInt
        * bitOrFastInt
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Subscribers: rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D1141
      
      GHC Trac Issues: #1405
      2f29ebbb
  8. 03 Dec, 2014 1 commit
  9. 19 Aug, 2014 1 commit
    • Austin Seipp's avatar
      build: require GHC 7.6 for bootstrapping · 527bcc41
      Austin Seipp authored
      
      
      Summary:
      Per the usual standards, a build of GHC is only compileable
      by the last two releases (e.g. 7.8 only by 7.4 and 7.6). To make sure
      we don't get suckered into supporting older compilers, let's remove
      this support now.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan:
      Try to bootstrap with GHC 7.4, watch it fail. Bootstrap
      with 7.6 or better, and everything works.
      
      Reviewers: hvr
      
      Reviewed By: hvr
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D167
      527bcc41
  10. 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
  11. 30 Jan, 2013 1 commit
  12. 29 Nov, 2012 1 commit
  13. 20 Jul, 2012 1 commit
  14. 12 Jun, 2012 1 commit
  15. 11 Jun, 2012 2 commits
  16. 05 Jun, 2012 1 commit
  17. 22 May, 2012 3 commits
  18. 12 Apr, 2012 1 commit
  19. 03 Apr, 2012 1 commit
  20. 30 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Include a stack trace in the panic message, when GHC is compiled profiled. · f85c084c
      Simon Marlow authored
      I tried this out on the panic we're currently getting for #3103:
      
      ghc-stage2: panic! (the 'impossible' happened)
        (GHC version 7.3.20111128 for x86_64-unknown-linux):
              tcIfaceGlobal (local): not found:
          base:GHC.Word.W#{d 6w}
          [(32R, Type constructor `base:GHC.Word.Word{tc 32R}'),
           (r6O, Identifier `base:GHC.Word.$fNumWord{v r6O}'),
           (r6P, Identifier `base:GHC.Word.$fEqWord{v r6P}'),
           (r6Q, Identifier `base:GHC.Word.$fNumWord1{v r6Q}'),
           (r6R, Identifier `base:GHC.Word.$fNumWord2{v r6R}'),
           (r6S, Data constructor `base:GHC.Word.W#{d r6S}'),
           (r6U, Identifier `base:GHC.Word.W#{v r6U}'),
           (r75, Identifier `base:GHC.Word.$fNumWord_$csignum{v r75}'),
           (r76, Identifier `base:GHC.Word.$fEqWord_$c/={v r76}'),
           (r77, Identifier `base:GHC.Word.$fEqWord_$c=={v r77}')]
      { Main.main
         GHC.defaultErrorHandler
          GHC.runGhc
           GhcMonad.>>=
            GhcMonad.>>=.\
             Main.main'
              Main.doMake
               GhcMake.load
                GhcMake.load2
                 GhcMake.upsweep
                  GhcMake.upsweep.upsweep'
                   GhcMake.reTypecheckLoop
                    GhcMake.typecheckLoop
                     GhcMake.typecheckLoop.\
                      TcRnMonad.initIfaceCheck
                       TcRnMonad.initTcRnIf
                        IOEnv.runIOEnv
                         IOEnv.thenM
                          IOEnv.thenM.\
                           TcIface.typecheckIface
                            TcIface.typecheckIface.\
                             LoadIface.loadDecls
                              LoadIface.loadDecl
                               TcIface.tcIfaceDecl
                                TcIface.tc_iface_decl
                                 TcIface.tcIdInfo
                                  MonadUtils.foldlM
                                   TcIface.tcIdInfo.tcPrag
                                    TcIface.tcUnfolding
                                     TcIface.tcPragExpr
                                      TcIface.tcIfaceExpr
                                       TcIface.tcIfaceAlt
                                        TcIface.tcIfaceDataCon }
      f85c084c
  21. 04 Nov, 2011 1 commit
  22. 12 Jul, 2011 1 commit
  23. 08 Dec, 2010 1 commit
  24. 29 Oct, 2010 2 commits
    • benl@ouroborus.net's avatar
      Cleanup comments and formatting only · 2f4e210f
      benl@ouroborus.net authored
      2f4e210f
    • benl@ouroborus.net's avatar
      Nicer error message for #3782 · 3a7e2b3a
      benl@ouroborus.net authored
      It now says:
      
      ghc-stage2: sorry! (this is work in progress)
        (GHC version 7.1.20101028 for i386-apple-darwin):
      	Vectorise.Builtins.indexBuiltin
          
          DPH builtin function 'sumTyCon' of size '11' is not yet implemented.
          This function does not appear in your source program, but it is needed
          to compile your code in the backend. This is a known, current limitation
          of DPH. If you want it to to work you should send mail to cvs-ghc@haskell.org
          and ask what you can do to help (it might involve some GHC hacking).
      
      
      I added 'pprSorry' that behaves like 'pprPanic' except it say sorry! instead 
      of panic!, and doesn't ask the user to report a bug. 
      3a7e2b3a
  25. 02 Jun, 2010 1 commit
  26. 27 Jan, 2010 2 commits
  27. 07 Jul, 2009 1 commit
  28. 01 Jul, 2009 1 commit
  29. 03 Oct, 2008 2 commits
  30. 26 Sep, 2008 1 commit
    • pepe's avatar
      Don't capture error calls in tryUser · ec197dfe
      pepe authored
      A previous patch slightly changed the semantics of tryUser.
      This patch restores the original behaviour
      (as expected in :print)
      ec197dfe
  31. 14 Sep, 2008 1 commit
  32. 31 Jul, 2008 1 commit
  33. 30 Jul, 2008 1 commit
  34. 20 Jul, 2008 1 commit