1. 29 Apr, 2017 1 commit
  2. 25 Apr, 2017 1 commit
    • Simon Marlow's avatar
      Don't setProgramDynFlags on every :load · 914842e5
      Simon Marlow authored
      Summary:
      setProgramDynFlags invalidates the whole module graph, forcing
      everything to be re-summarised (including preprocessing) on every
      :reload.
      
      Looks like this was a bad regression in 8.0, but we didn't notice
      because there was no test for it.  Now there is!
      
      Test Plan:
      * validate
      * new unit test
      
      Reviewers: bgamari, triple, austin, niteria, erikd, jme
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3398
      914842e5
  3. 18 Apr, 2017 1 commit
  4. 05 Apr, 2017 1 commit
  5. 04 Apr, 2017 1 commit
  6. 02 Apr, 2017 1 commit
  7. 01 Apr, 2017 1 commit
    • Simon Marlow's avatar
      Optimise common cases of GHC.setProgramDynFlags · 3b5f786c
      Simon Marlow authored
      * If the package flags haven't changed, don't do initPackages (which
        might take multiple seconds in extreme cases)
      
      * Provide a way to change the log_action without invalidating the
        summary cache.
      
      Test Plan: validate
      
      Reviewers: niteria, bgamari, austin, erikd, ezyang
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3392
      3b5f786c
  8. 28 Mar, 2017 1 commit
  9. 24 Mar, 2017 1 commit
    • Rufflewind's avatar
      Allow colors to be customized · adf27d61
      Rufflewind authored
      Allow customization of diagnostic colors through the GHC_COLORS
      environment variable.  Some color-related code have been refactored to
      PprColour to reduce the circular dependence between DynFlags,
      Outputable, ErrUtils.  Some color functions that were part of Outputable
      but were never used have been deleted.
      
      Test Plan: validate
      
      Reviewers: austin, hvr, bgamari, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: dfeuer, rwbarton, thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3364
      adf27d61
  10. 02 Mar, 2017 1 commit
  11. 10 Feb, 2017 1 commit
  12. 09 Feb, 2017 1 commit
  13. 20 Jan, 2017 1 commit
    • Phil de Joux's avatar
      Show explicit quantifiers in conflicting definitions error · 33140f41
      Phil de Joux authored
      This fixes #12441, where definitions in a Haskell module and its boot
      file which differed only in their quantifiers produced a confusing error
      message. Here we teach GHC to always show quantifiers for these errors.
      
      Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2734
      
      GHC Trac Issues: #12441
      33140f41
  14. 16 Nov, 2016 2 commits
    • Simon Marlow's avatar
      Generalise the implicit prelude import · d3542fad
      Simon Marlow authored
      Now it's possible to have two lists of imports:
      * extra_imports are imports that are always added to the context
      * prelude_imports are imports that are added if we don't have
        any open modules in scope.
      
      No UI changes or new commands are added for now.  This was functionality
      that we needed in our customized GHCi at Facebook, so I wanted to get it
      upstream to reduce the differences between our version and the upstream
      version.
      d3542fad
    • Simon Marlow's avatar
      Avoid calling newDynFlags when there are no changes · 7acee066
      Simon Marlow authored
      This is a small optimisation for :set and :unset
      7acee066
  15. 03 Nov, 2016 1 commit
  16. 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
  17. 08 Oct, 2016 1 commit
  18. 31 Aug, 2016 1 commit
  19. 23 Jun, 2016 1 commit
  20. 01 May, 2016 1 commit
    • niksaz's avatar
      Greater customization of GHCi prompt · 533037cc
      niksaz authored
      This patch is trying to redesign the :set prompt option to take not a
      String but a Haskell function, like [String] -> Int -> IO String, where
      [String] is the list of the names of the currently loaded modules and
      Int is the line number. Currently you may set prompt function with
      **:set promt-function [String] -> Int -> IO String** option and old
      version is also available - :set prompt String.
      
      So, it looks like I've almost completed this patch:
      
      1) Now we have a lot of escape sequences - 13 to be exact. Most of them
         are similar to bash prompt escape sequences. Thus they are quite handy.
      
      2) We may use the special escape sequence to call shell functions, for
         example "%call(ls -l -a)".
      
      3) We may use :set prompt-function to set PFunction to handle prompt.
         It is just [String] -> Int -> IO String.
      
      Reviewers: erikd, austin, mpickering, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2084
      
      GHC Trac Issues: #5850
      533037cc
  21. 12 Mar, 2016 1 commit
  22. 05 Mar, 2016 1 commit
  23. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  24. 11 Feb, 2016 1 commit
  25. 27 Jan, 2016 1 commit
  26. 22 Jan, 2016 1 commit
  27. 18 Jan, 2016 1 commit
  28. 17 Jan, 2016 1 commit
  29. 13 Jan, 2016 1 commit
  30. 09 Jan, 2016 1 commit
    • Rik Steenkamp's avatar
      Reject import declaration with semicolon in GHCi · a84c21eb
      Rik Steenkamp authored
      Now GHCi rejects input containing an import declaration and semicolon,
      and prints an appropriate error message. Before, the stuff after an
      import declaration and semicolon got ignored (most of the time), without
      telling the user about it. As the default behaviour of GHCi is to reject
      multiple commands in a single input, we extend this behaviour to import
      commands.
      
      This patch fixes #10663.
      
      (See https://phabricator.haskell.org/D1518 for the introduction of
      `is_import` and `is_decl`.)
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1726
      
      GHC Trac Issues: #10663
      a84c21eb
  31. 08 Jan, 2016 1 commit
    • Simon Marlow's avatar
      Enable stack traces with ghci -fexternal-interpreter -prof · 6be09e88
      Simon Marlow authored
      Summary:
      The main goal here is enable stack traces in GHCi.  After this change,
      if you start GHCi like this:
      
        ghci -fexternal-interpreter -prof
      
      (which requires packages to be built for profiling, but not GHC
      itself) then the interpreter manages cost-centre stacks during
      execution and can produce a stack trace on request.  Call locations
      are available for all interpreted code, and any compiled code that was
      built with the `-fprof-auto` familiy of flags.
      
      There are a couple of ways to get a stack trace:
      
      * `error`/`undefined` automatically get one attached
      * `Debug.Trace.traceStack` can be used anywhere, and prints the current
        stack
      
      Because the interpreter is running in a separate process, only the
      interpreted code is running in profiled mode and the compiler itself
      isn't slowed down by profiling.
      
      The GHCi debugger still doesn't work with -fexternal-interpreter,
      although this patch gets it a step closer.  Most of the functionality
      of breakpoints is implemented, but the runtime value introspection is
      still not supported.
      
      Along the way I also did some refactoring and added type arguments to
      the various remote pointer types in `GHCi.RemotePtr`, so there's
      better type safety and documentation in the bridge code between GHC
      and ghc-iserv.
      
      Test Plan: validate
      
      Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1747
      
      GHC Trac Issues: #11047, #11100
      6be09e88
  32. 22 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244 · 1faf1fca
      Edward Z. Yang authored
      
      
      Summary:
      The basic idea is that we have a new set of "exposed modules"
      which are /only/ used for plugins, i.e. -fplugin Foo and
      --frontend Foo.  You can interact with this namespace
      using the flags -plugin-package-id and -plugin-package.
      By default, this namespace contains all modules in the
      user namespace (as before), but you can toggle that using
      -hide-all-plugin-packages.
      
      There is one nasty hack: GhcMake respects -fplugin in
      GHC_OPTIONS to make local plugins work correctly.  It also
      bails out of you have an import of a module which doesn't
      exist locally or in the package database.  The upshot is
      that we need to be sure to check in the plugin modules
      too, so we don't give a spurious failure when a plugin
      is in the plugin namespace but not the main namespace.
      A better way to fix this would be to distinguish between
      plugin and normal dependencies in ModSummary.
      
      I cheated a little and tweaked a few existing plugins
      tests to exercise the new code paths.
      
      TODO: Documentation
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin, simonpj, duncan
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1661
      
      GHC Trac Issues: #11244
      1faf1fca
  33. 21 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Rename GHCi's UI modules into GHCi.UI(.*) · 55250a63
      Herbert Valerio Riedel authored
      Further work refactoring and enhancing GHCi will make it desirable to
      split up GHCi's code-base into multiple modules with specific functions,
      and rather than have several top-level 'Ghci*' modules, it's nicer to
      have a common namespace. This commit is provides the basis for that.
      
      Note that the remaining GHCi.* namespace belongs to the new `ghci`
      package.
      
      Differential Revision: https://phabricator.haskell.org/D1593
      55250a63
    • Simon Marlow's avatar
      Maintain cost-centre stacks in the interpreter · c8c44fd9
      Simon Marlow authored
      Summary:
      Breakpoints become SCCs, so we have detailed call-stack info for
      interpreted code.  Currently this only works when GHC is compiled with
      -prof, but D1562 (Remote GHCi) removes this constraint so that in the
      future call stacks will be available without building your own GHCi.
      
      How can you get a stack trace?
      
      * programmatically: GHC.Stack.currentCallStack
      * I've added an experimental :where command that shows the stack when
        stopped at a breakpoint
      * `error` attaches a call stack automatically, although since calls to
        `error` are often lifted out to the top level, this is less useful
        than it might be (ImplicitParams still works though).
      * Later we might attach call stacks to all exceptions
      
      Other related changes in this diff:
      
      * I reduced the number of places that get ticks attached for
        breakpoints.  In particular there was a breakpoint around the whole
        declaration, which was often redundant because it bound no variables.
        This reduces clutter in the stack traces and speeds up compilation.
      
      * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
        other small cleanups
      
      Test Plan: validate
      
      Reviewers: ezyang, bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1595
      
      GHC Trac Issues: #11047
      c8c44fd9
  34. 20 Dec, 2015 1 commit
  35. 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
  36. 16 Dec, 2015 1 commit
    • quchen's avatar
      Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flags · 2206fa8c
      quchen authored
      This also updates the user's guide to refer to the `-W`-based warning
      flags by default.
      
      Quoting the release note entry:
      
      | Warnings can now be controlled with `-W(no-)...` flags in addition to
      | the old `-f(no-)warn...` ones. This was done as the first part of a
      | rewrite of the warning system to provide better control over warnings,
      | better warning messages, and more common syntax compared to other
      | compilers. The old `-fwarn...`-based warning flags will remain
      | functional for the forseeable future.
      
      This is part of
      https://ghc.haskell.org/wiki/Design/Warnings
      and addresses #11218
      
      Reviewed By: hvr, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1613
      2206fa8c
  37. 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
  38. 08 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Refactor GHCi Command type; allow "hidden" commands · 7997d6c0
      Herbert Valerio Riedel authored
      This transforms the 'Command' tuple into a record which is
      easier to extend.
      
      While at it, this refactoring turns the IDE `:complete` into a hidden
      command excluded from completion.
      
      The next obvious step is to add a summary text field for constructing
      the `:help` output (as well as allowing to get `:help <CMD>` for single
      commands.
      
      This is a preparatory refactoring for D1240 / #10874
      
      Reviewed By: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1590
      7997d6c0