| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Requires bumping several submodules.
Test Plan: ./validate
Reviewers: hvr, bgamari
Subscribers: thomie, carter
GHC Trac Issues: #15042
Differential Revision: https://phabricator.haskell.org/D4604
|
| |
|
|
|
|
| |
See Phab:D4377 for the rationale. We will try this again.
This reverts commit 7c173b9043f7a9a5da46c5b0cc5fc3b38d1a7019.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done for consistency. We usually call the package file the same name the
folder has. The move into `utils` is done so that we can move the library into
`libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
`iserv.cabal` apart. This will make building the cross compiler with TH
simpler, because we can build the library and proxy as separate packages.
Reviewers: bgamari, simonmar, goldfire, erikd
Reviewed By: simonmar
Subscribers: tdammers, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4377
|
| |
|
|
| |
The ghc-8.4 branch has now been cut. Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin, snowleopard
Subscribers: angerman, rwbarton, thomie, int-e
Differential Revision: https://phabricator.haskell.org/D4042
|
| |
|
|
|
|
|
|
|
| |
The output is not being checked in the test suite.
However other tools may check it for obtaining the status
of the remote slave.
So I'd suggest to merge this to 8.2 branch, in order to not
fragment the tooling's checks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the forkIO into the `startSlave` function from the
`startSlave'` function, such that this allows consumers to call
`forkSlave'` if they want the blocking behaviour.
Reviewers: bgamari, austin
Reviewed By: bgamari
Subscribers: Ericson2314, ryantrinkle, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3601
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we load non absolute pathed .so's this usually implies that we expect the
system to have them in place already, and hence we should not need to ship them.
Without the absolute path to the library, we are also unable to open and send
said library. Thus we'll do library shipping only for libraries with absolute
paths.
Reviewers: austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: simonmar, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3469
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default GhcThreaded is set by
```
GhcThreaded = $(if $(findstring thr,$(GhcRTSWays)),YES,NO)
```
so it seems incorrect to try to build iserv with -threaded when
GhcThreaded is not set. This came up when I was building GHC with
some strange combination of flavours (debugged and profiled but not
threaded).
Test Plan: harbormaster
Reviewers: simonmar, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3429
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, austin
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the introduction of -fexternal-interpreter we are
now able to compile template haskell via an extern iserv process.
This however is restricted to the same host, and can therefore
not be used with crosscompilers where the iserv slave process
needs to run on a different machine than the cross compiling
haskell compiler.
This diff breaks up iserv into a library and the iserv-bin binary.
It also introduces the iserv-proxy, a proxy instance that the
haskell compiler can talk to, and which forwards the calls
to the iserv slave on a different machine, as well as providing
some extra functionarily (sending files that are not available
on the machine the slave runs on), as well as forwarding from
the slave to the haskell compiler, when the slave needs to
interrogate the haskell compiler.
The iserv library now also exports the startSlave function to be
called by the application that implements the slave on the target.
The simplest such app would probably look something like:
```
extern void startServ(bool, const char *);
int main(int argc, char * argv[]) {
hs_init(NULL, NULL);
startServ(false,"/tmp");
while(1);
}
```
Special thanks to Shea Levy for the first draft of the iserv-remote,
from which I took some inspiration.
The `Buildable` flags are due to ghc-cabal not being able to build
more than a single target. Please note that only the stock iserv-bin
is supposed to be built *with* ghc. The library and proxy are supposed
to be built outside of ghc. Yet I believe that this code should live
together with iserv.
Reviewers: simonmar, ezyang, goldfire, austin, rwbarton, bgamari
Reviewed By: simonmar
Subscribers: luite, ryantrinkle, shlevy, thomie
Differential Revision: https://phabricator.haskell.org/D3233
|
| |
|
|
| |
Bumps haddock submodule
|
| |
|
|
|
| |
This reverts commit 5dce2160a1b361eba7d0109d314246c8ec97878b as it
didn't build.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes build failure on Solaris which is caused
by usage --export-dynamic linker parameter. This parameter is not
supported by Solaris linker. The param itself was added by D2590
Reviewers: bgamari, simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables loading dynamic libraries that refer to the RTS. I just
came across somewhere I needed to do that, and without
`--export-dynamic` it's impossible.
For now we'll only support that when using `-fexternal-interpreter`,
because the dynamic symbol table for GHC itself is much bigger.
Test Plan: validate
Reviewers: niteria, austin, erikd, bgamari
Reviewed By: bgamari
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2590
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: simonmar, erikd, austin
Reviewed By: simonmar, erikd
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D2494
GHC Trac Issues: #12491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This annotates the splice point with 'HsSpliced ref e' where 'e' is the
result of the splice. 'ref' is a reference that the typechecker will fill with
the local type environment.
The finalizer then reads the ref and uses the local type environment, which
causes 'reify' to find local variables when run in the finalizer.
Test Plan: ./validate
Reviewers: simonpj, simonmar, bgamari, austin, goldfire
Reviewed By: goldfire
Subscribers: simonmar, thomie, mboes
Differential Revision: https://phabricator.haskell.org/D2286
GHC Trac Issues: #11832
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add more Notes and signposts across the codebase to help navigation.
Test Plan: validate
Reviewers: goldfire, simonpj, austin, ezyang, hvr, bgamari, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
From a suggestion by @goldfire: clean up the message types, so that
rather than one Message type with all the messages, we have a separate
THMessage type for messages sent back to GHC during TH execution. At
the same time I also removed the QDone/QFailed/QException messages
into their own type, and made the result type of RunTH more accurate.
Test Plan: validate
Reviewers: goldfire, ezyang, austin, niteria, bgamari, erikd
Subscribers: thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D2356
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes the needed changes to make RemoteGHCi work on Windows.
The approach passes OS Handles areound instead of the Posix Fd
as on Linux.
The reason is that I could not find any real documentation about
the behaviour of Windows w.r.t inheritance and Posix FDs.
The implementation with Fd did not seem to be able to find the Fd
in the child process. Instead I'm using the much better documented
approach of passing inheriting handles.
This requires a small modification to the `process` library.
https://github.com/haskell/process/pull/52
Test Plan: ./validate On Windows x86_64
Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
Reviewed By: simonmar
Subscribers: #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D1836
GHC Trac Issues: #11100
|
| | |
|
| |
|
|
| |
This updates the haddock submodule
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
(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
|
