| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We had a duplicate copy of the code for --make and for -c
which was a pain. The call graph looked something like this:
compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend
hscCompileOneShot ---^
with genericHscCompileGetFrontendResult and hscCompileOneShot
duplicating logic for deciding whether or not recompilation
was needed.
This patchset fixes it, so now everything goes through this call-chain:
compileOne (--make entry point)
Calls hscIncrementCompile, invokes the pipeline to do codegen
and sets up linkables.
hscIncrementalCompile (-c entry point)
Calls hscIncrementalFrontend, and then simplifying,
desugaring, and writing out the interface.
hscIncrementalFrontend
Performs recompilation avoidance, if recompilation needed,
does parses typechecking.
I also cleaned up some of the MergeBoot nonsense by introducing
a FrontendResult type.
NB: this BREAKS #8101 again, because I can't unconditionally desugar
due to Haddock barfing on lint, see #10600
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, bgamari, simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1302
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed
to behave exactly like $(n "...blah..."). But it doesn't! This was outright
wrong: quasiquotes were being run even inside brackets.
Now that TH supports both typed and untyped splices, a quasi-quote is properly
regarded as a particular syntax for an untyped splice. But apart from that
they should be treated the same. So this patch refactors the handling of
quasiquotes to do just that.
The changes touch quite a lot of files, but mostly in a routine way.
The biggest changes by far are in RnSplice, and more minor changes in
TcSplice. These are the places where there was real work to be done.
Everything else is routine knock-on changes.
* No more QuasiQuote forms in declarations, expressions, types, etc.
So we get rid of these data constructors
* HsBinds.QuasiQuoteD
* HsExpr.HsSpliceE
* HsPat.QuasiQuotePat
* HsType.HsQuasiQuoteTy
* We get rid of the HsQuasiQuote type altogether
* Instead, we augment the HsExpr.HsSplice type to have three
consructors, for the three types of splice:
* HsTypedSplice
* HsUntypedSplice
* HsQuasiQuote
There are some related changes in the data types in HsExpr near HsSplice.
Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour.
* In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one.
A smaller, clearer interface.
* We have to update the Haddock submodule, to accommodate the hsSyn changes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The runMeta hook can be used to override how metaprogramming expressions
are evaluated. It makes the metaprogramming request types explicit and
has access to the TcM monad. This makes it a much more convenient starting
point for implementing out of process Template Haskell than the existing
hscCompileCoreExpr hook.
Reviewers: hvr, edsko, austin, simonpj
Reviewed By: austin
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D501
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GlobalId'
The trouble was that my changes made a lot more files transitively link with
DynFlags, which is the root module for the revolting Windows dll-split stuff.
Anyway this patch fixes it, in a good way:
- Make GHC/Hooks *not* import DsMonad, because DsMonad imports too
much other stuff (notably tcLookup variants). Really, Hooks depends
only on *types* not *code*.
- To do this I need the DsM type, and the types it depends on,
not to be part of DsMonad. So I moved it to TcRnTypes, which is
where the similar pieces for the TcM and IfM monads live.
- We can then delete DsMonad.hs-boot
- There are a bunch of knock-on change, of no great significance
|
|
|
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
