| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Updates a number of submodules.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate on lots of platforms
Reviewers: erikd, simonmar, austin
Reviewed By: erikd, simonmar
Subscribers: michalt, thomie
Differential Revision: https://phabricator.haskell.org/D2699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the case of building a stage1 compiler. `hschooks.c` will be
built by stage0 `ghc` and linked against the `stage0` RTS. Despite this
it was #including the stage1 `Rts.h`. There is, of course, no guarantee
that this is ABI-compatible with the stage0 RTS and when they diverge
Bad Things happen (e.g. bells ringing at inappropriate times in D2699).
Test Plan: Validate
Reviewers: simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to ensure that we don't include Rts.h from bootstrap compiler.
See #12796.
Test Plan: Validate
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2698
GHC Trac Issues: #12796
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This is a small optimisation for :set and :unset
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This also changes the backpack Renaming type to use a Maybe for the
renameTo field, to more accurately reflect the parsed source.
Updates haddock submodule to match AST changes
Test Plan: ./validate
Reviewers: ezyang, bgamari, austin
Reviewed By: bgamari
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously BinIface had some dedicated logic for handling tuple names in
the symbol table. As it turns out, this logic was essentially dead code
as it was superceded by the special handling of known-key things. Here
we cull the tuple code-path and use the known-key codepath for all
tuple-ish things.
This had a surprising number of knock-on effects,
* constraint tuple datacons had to be made known-key (previously they
were not)
* IfaceTopBndr was changed from being a synonym of OccName to a
synonym of Name (since we now need to be able to deserialize Names
directly from interface files)
* the change to IfaceTopBndr complicated fingerprinting, since we need
to ensure that we don't go looking for the fingerprint of the thing
we are currently fingerprinting in the fingerprint environment (see
notes in MkIface). Handling this required distinguishing between
binding and non-binding Name occurrences in the Binary serializers.
* the original name cache logic which previously lived in IfaceEnv has
been moved to a new NameCache module
* I ripped tuples and sums out of knownKeyNames since they introduce a
very large number of entries. During interface file deserialization
we use static functions (defined in the new KnownUniques module) to
map from a Unique to a known-key Name (the Unique better correspond
to a known-key name!) When we need to do an original name cache
lookup we rely on the parser implemented in isBuiltInOcc_maybe.
* HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
* Lots of comments were sprinkled about describing the new scheme.
Updates haddock submodule.
Test Plan: Validate
Reviewers: niteria, simonpj, austin, hvr
Reviewed By: simonpj
Subscribers: simonmar, niteria, thomie
Differential Revision: https://phabricator.haskell.org/D2467
GHC Trac Issues: #12532, #12415
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements Backpack for GHC. It's a big patch but I've tried quite
hard to keep things, by-in-large, self-contained.
The user facing specification for Backpack can be found at:
https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst
A guide to the implementation can be found at:
https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst
Has a submodule update for Cabal, as well as a submodule update
for filepath to handle more strict checking of cabal-version.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, simonmar, bgamari, goldfire
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1482
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: thomie, bgamari, austin
Reviewed By: thomie, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2461
GHC Trac Issues: #9089
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically per-component macros and multiple libraries.
Contains Cabal submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: austin, bgamari
Subscribers: hvr, thomie
Differential Revision: https://phabricator.haskell.org/D2059
|
|
|
|
|
|
| |
See the user's guide entry or the Note [TcRnExprMode] in TcRnDriver.
Test cases: ghci/scripts/T{10963,11975}
|
|
|
|
|
|
|
|
| |
Reviewed by: bgamari
Differential Revision: https://phabricator.haskell.org/D2331
GHC Trac Issues: #12192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also makes the behavior the same with frontend plugin errors --
frontend was failing with an exception (`CmdLineError`) while the
simplifier was just ignoring plugins. Now we abort with `CmdLineError`
in both cases with a slightly improved error message.
Test Plan:
- add tests (will add tests once #12197 is implemented)
- validate (done)
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2334
GHC Trac Issues: #11690
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
CPU time is never very accurate, and it broke completely with
-fexternal-interpreter which runs the interpreted computations in a
separate process.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1991
GHC Trac Issues: #9887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses GHCi load/reload space leaks which could be
fixed without adversely affecting performance.
Test Plan: make test "TEST=T4029"
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D1950
GHC Trac Issues: #4029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all flags were present in user suggest and completion. This commit
removes the deprecated ones from there. It is done by saving deprecation info
at the moment of flag definition.
Reviewers: rwbarton, austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D1883
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: thomie, austin, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1833
GHC Trac Issues: #11481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also don't print it if the user specifically requested
non-verbose output with -v0.
Since this means there is no longer any test that checks
for the message, add such a test.
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1817
GHC Trac Issues: #11478
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: simonmar, thomie, austin
Reviewed By: austin
Subscribers: alanz
Differential Revision: https://phabricator.haskell.org/D1789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix operator completions: list of suitable completions only rather than
everything from imported modules.
Signed-off-by: Arthur Fayzrakhmanov (Артур Файзрахманов) <heraldhoi@gmail.com>
ghc: fix operator completions
Reviewers: austin, hvr, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1058
GHC Trac Issues: #10576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: austin, thomie, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D1756
GHC Trac Issues: #11389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various people (myself included) have complained about the lack of
useful descriptions for the various packages included in GHC's source
tree. Fix this.
Test Plan: Validate
Reviewers: austin, thomie
Reviewed By: thomie
Subscribers: angerman, ezyang
Differential Revision: https://phabricator.haskell.org/D1736
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Working on some code using the GHC API, I found these
functions were useful and wished they were exported. This
commit exports them.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: hvr, thomie
Differential Revision: https://phabricator.haskell.org/D1710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin, hvr
Reviewed By: hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1712
GHC Trac Issues: #9614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60).
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Edward 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
This has been factored out of D1673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the new commands `:all-types`, `:loc-at`, `:type-at`, and
`:uses` designed for editor-integration (such as Emacs' `haskell-mode`).
This was originally implemented by Chris Done on
https://github.com/chrisdone/ghci-ng
and has been in use by Emacs' `haskell-mode` for over a year already,
and closely missed the GHC 7.10 release back then.
I've squashed the commits, rebased to GHC HEAD, and heavily refactored and
improved the patch.
Tests will be added in a separate commit.
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1240
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Frontend plugins enable users to write plugins to replace
GHC major modes. E.g. instead of saying
ghc --make A B C
a user can now say
ghc --frontend GHC.Frontend.Shake A B C
which might provide an alternative implementation of a multi-module
build. For more details, see the manual entry.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonmar, bgamari, austin, simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1598
GHC Trac Issues: #11194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ideally, we'd have the more general
instance (MonadTrans t, Monad m, HasDynFlags m) => HasDynFlags (t m) where
getDynFlags = lift getDynFlags
definition. However, that one would overlap with the `HasDynFlags (GhcT m)`
instance. Instead we define instances for a couple of common Monad
transformers explicitly in order to avoid nasty overlapping instances.
This is a preparatory refactoring for #10874
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1581
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to reach the GhciState without having to keep
track how many Monad transformer layers sit on top of the
GHCi monad.
While at it, this also refactors code to make more use of the
existing `modifyGHCiState` operation.
This is a preparatory refactoring for #10874
Differential Revision: https://phabricator.haskell.org/D1582
|
|
|
|
|
|
|
| |
It makes little sense to have __GLASGOW_HASKELL__ conditional
code inside GHCi's source-code, as GHCi is only ever build
by the current stage1 GHC, whose version is assumed to be the
same as the GHCi version being built.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D1518
GHC Trac Issues: #9015
|