| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 Cabal library now commits `Lexer.hs` directly to the source tree,
so the build step where we'd call alex ourselves to generate that file
is no longer necessary, nor will it work.
See also: https://ghc.haskell.org/trac/ghc/ticket/14459
Reviewers: bgamari, hvr
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14459
Differential Revision: https://phabricator.haskell.org/D4240
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop the GHC.Prim madness with `virtual-module` support from cabal.
Needs https://github.com/haskell/cabal/pull/4875.
Bumps submodule libraries/Cabal to include the necessary logic for `virtual-module`.
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4179
|
|
|
|
|
|
|
|
| |
Unfortunately this (ironically) ended up breaking bindist testing since
we didn't have a package-data.mk. Unfortunately there is no easy way to
fix this.
This reverts commit 1e9f90af7311c33de0f7f5b7dba594725596d675.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are needed by the testsuite and consequently must be shipped in
the testsuite tarball to ensure that we can test binary distributions.
See #13897.
Test Plan: Validate
Reviewers: austin
Subscribers: snowleopard, rwbarton, thomie
GHC Trac Issues: #13897
Differential Revision: https://phabricator.haskell.org/D4039
|
|
|
|
|
|
|
|
|
|
| |
This effectively broke `make sdist`; the surprising thing is that
./validate didn't catch this (and thus the buildbots didn't either).
Also, I would have expected `EXTRA_PACKAGES` to be populated by the
data in `./packages` which already encodes that information...
This is a follow-up to 02ff70563e490d2a7f3141eab7229803c523da57
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a preparation for `haskeline` picking up a dependency on `stm`
real soon now. See https://github.com/judah/haskeline/pull/61 for details.
If we figure out a way to not bundle the libraries depended upon by the
GHCi executable in the global package database (see #8919 for the original
reason why we had to start bundling terminfo/haskeline in the first place)
we can get rid of `stm` again...
On the bright side, we were able to avoid uploading new `stm` releases for
over two years already, so it shouldn't cause too much trouble if GHC imposes
a strong preference on the `stm` package's version (this most likely will
mostly affect Linux distributions & similiar).
While at it, this also update the stm submodule to include relaxed
bounds to allow the upcoming base-4.11 version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean
up introduces a shared data structure to carry the arguments we pass to
each tool so that corresponding flags are next to each other. It drops
the hard coded data layouts in favor of using `-mtriple` and have LLVM
infer them. Furthermore we add `clang` as a proper tool, so we don't
rely on assuming that `clang` is called `clang` on the `PATH` when using
`clang` as the assembler. Finally this diff also changes the type of
`optLevel` from `Int` to `Word`, as we do not have negative optimization
levels.
Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon
Reviewed By: kavon
Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
kavon, simonmar, thomie, erikd, snowleopard
Differential Revision: https://phabricator.haskell.org/D3352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This tool can be used to generate dll's for any list of object files
given to it. It will then repartition them automatically to fit within
a dll and generates as many dll's as needed to do this. Cyclic dependencies
between these generated dlls are handle automatically so there is no need
to tell it how to partition.
It is also a lot more general than `dll-split` as it is able to split any
package not just `libGHC`. It also uses a trick using GNU style import libraries
to hide the splitting from the rest of the pipeline. Which means come linking time
you don't need to know which dll contains what symbol or how many split dlls were
created.
The import libraries are by default created with libtool. However since libtool is BFD
based it is very slow. So if present and detected by configure the `genlib` tool
from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
More detailed explaination of the process can be found here
https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes dll-split from the code base, the reason is dll-split
no longer makes any sense. It was designed to split a dll in two, but we
now already have many more symbols than would fit inside two dlls. So we
need a third one. This means there's no point in having to maintain this
list as it'll never work anyway and the solution isn't scalable.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3882
|
|
|
|
|
|
|
|
| |
Reviewers: austin, hvr
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bit me today: I was in validate mode without realising it and "make
clean" didn't help. I don't see a reason for this to be in distclean, as
it isn't generated by ./configure, which is the rule described in
https://ghc.haskell.org/trac/ghc/wiki/Building/Using
Test Plan: Is there a reason for this to be in distclean?
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cabal's parser has been rewritten in terms of Parsec (which is not
enabled yet in Cabal-2.0 by default, but can be enabled by a cabal
flag). The plan for Cabal is to drop support for the non-parsec parser,
so we need to prepare GHC to cope with new situation.
However, this means that lib:Cabal requires three new library
dependency submodules,
- parsec
- text
- mtl
What complicates matters is that we need to build `ghc-cabal` early on
during the bootstrap phase which currently needs to invoke `ghc --make`
directly. So these additional dependencies need to be integrated into
the monolithic `ghc --make` invocation which produces the `ghc-cabal`
executable.
Test Plan: `./validate --fast` passed
Reviewers: austin, bgamari
Subscribers: erikd, phadej, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several executables inexplicably appear twice in bindist.list, which
ends up producing multiple tar file entries, consequently breaking BSD
tar during extraction. I spent a fair amount of time trying to work out
where these duplicates were coming from to no avail. Since Hadrian is
right around the corner I'm satisfied with a terrible hack: just uniq
bindist.list before producing the bindist tarball.
Test Plan: Validate
Reviewers: austin
Subscribers: rwbarton, thomie
GHC Trac Issues: #13979, #13974
Differential Revision: https://phabricator.haskell.org/D3767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This copies the subset of Hoopl's functionality needed by GHC to
`cmm/Hoopl` and removes the dependency on the Hoopl package.
The main motivation for this change is the confusing/noisy interface
between GHC and Hoopl:
- Hoopl has `Label` which is GHC's `BlockId` but different than
GHC's `CLabel`
- Hoopl has `Unique` which is different than GHC's `Unique`
- Hoopl has `Unique{Map,Set}` which are different than GHC's
`Uniq{FM,Set}`
- GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is
needed just to filter the exposed functions (filter out some of the
Hoopl's and add the GHC ones)
With this change, we'll be able to simplify this significantly.
It'll also be much easier to do invasive changes (Hoopl is a public
package on Hackage with users that depend on the current behavior)
This should introduce no changes in functionality - it merely
copies the relevant code.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Test Plan: ./validate
Reviewers: austin, bgamari, simonmar
Reviewed By: bgamari, simonmar
Subscribers: simonpj, kavon, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3616
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise this will fail if the prefix path contains spaces. Thanks to
marinelli for pointing this out.
Test Plan: Validate
Reviewers: austin
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When user installs _native_ build ghc executable is renamed
from '$(libexec)/bin/ghc-stage<N>' to '$(libexec)/bin/ghc'.
But not on windows!
In case of _cross-compiler_ rename should happen only
for '$(libexec)/bin/ghc-stage<N>' runnable on non-windows
platform.
Before the change '$(libexec)/bin/ghc-stage<N>' rename happened
for any compiler not targeting windows.
After the patch rename also happens for '$(libexec)/bin/ghc-stage1'
cross-compiler built for linux targeting windows (Stage1Only=YES case).
Or on a concrete example:
# host is x86_64-pc-linux-gnu
$ ./configure --target=i686-w64-mingw32
$ make install Stage1Only=YES
Before the change the layout was:
- '$(libexec)/bin/ghc-stage1' was installed
- bin/ghc contained 'exec $(libexec)/bin/ghc' # missing file!
After the change:
- '$(libexec)/bin/ghc' was installed
- bin/ghc contained 'exec $(libexec)/bin/ghc' # present file
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rebuild package.cache to ensure that it's newer than the package
database registration files, avoiding out-of-date cache warnings from
ghc-pkg. See #13375.
Test Plan: `make install`, run `ghc-pkg list`, look for out-of-date
cache warning
Reviewers: austin
Subscribers: rwbarton, thomie
GHC Trac Issues: #13375
Differential Revision: https://phabricator.haskell.org/D3569
|
|
|
|
|
| |
This is a follow-up to df6794035f1e4397d89896f329525e5368b7d1cc
which missed `INSTALL_BINS`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a derivation of a patch from @jophish.
This is necessary due to `haskeline`'s `terminfo` flag being marked as
`Manual` as of 43d7fa106027fcd4ec7f443923a8dd5b8c169f9c.
Reviewers: jophish, bgamari, austin
Reviewed By: bgamari
Subscribers: rwbarton, thomie, jophish
Differential Revision: https://phabricator.haskell.org/D3493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempt to install cross-compiled mingw32 GHC built on linux failed as:
$ make install DESTDIR=$(pwd)/__i__
"mv" "$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2" \
"$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc"
mv: failed to stat
'$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2': \
No such file or directory
The rename should not be performed for windows targets.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change fixes case of installing cross-built GHC
from bindist (BINDIST=YES) on TARGET.
In this case we need to use TARGET tools in `INSTALLED_GHC{,_PKG}_REAL`.
The original change is provided by Fangrui Song
as pull request https://github.com/ghc/ghc/pull/34
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When cross-built GHC is being installed one of
latest steps is to register installed libraries
with 'ghc-pkg'.
GHC uses freshly installed 'ghc-pkg' and 'ghc-stage2'
for that.
Tested as:
./configure --target=aarch64-unknown-linux-gnu
make install DESTDIR=$(pwd)/__s2 STRIP_CMD=:
Before the change install failed on ghc-pkg execution phase:
".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg" \
--force \
--global-package-db \
".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/package.conf.d" \
update rts/dist/package.conf.install
/bin/sh: .../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg: \
No such file or directory
To avoid breakage we use 'ghc' and 'ghc-pkg' built by stage0.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make install' on stage2 crosscompiler
Reviewers: rwbarton, austin, bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3432
|
|
|
|
| |
This accidentally regressed in D3177.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a common thing that users who cross-compile must fight against.
It turns out that it's pretty straightforward to make is convenient.
Test Plan: Cross compile without a target `ncurses` available
Reviewers: danharaj, hvr, erikd, austin, rwbarton
Subscribers: rwbarton, thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build system uses the CrossCompiling variable to decide whether or
not we should build various packages that must be built using the
compiler. Consequently, it is important that we persist its value in
the binary distribution so we know during `make install` not to go
looking for files that would have been built for these packages. Failing
to do this causes #13325.
Test Plan: Cross compile, `make binary-dist`, and try installing the
binary distribution on the target
Reviewers: hvr, austin, trofi, rwbarton
Reviewed By: trofi, rwbarton
Subscribers: carter, trofi, rwbarton, erikd, thomie, snowleopard, davean
Differential Revision: https://phabricator.haskell.org/D3187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The plan is to release a separate library, 'compact', which gives a
friendly user-facing interface. This library is just enough so that we
can make sure the functionality is working in GHC.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: bgamari, dfeuer, austin, simonmar, hvr
Subscribers: thomie, erikd, snowleopard
Differential Revision: https://phabricator.haskell.org/D3206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
This was originally added in https://phabricator.haskell.org/D2826
but that led to a compatibility issue with ghc 7.10.x on Windows.
That's fixed here and the revert reverted.
Reviewers: goldfire, hvr, austin, bgamari, Phyx
Reviewed By: Phyx
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2884
GHC Trac Issues: #13008
|
|
|
|
| |
This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
Reviewers: simonmar, goldfire, austin, hvr, bgamari
Reviewed By: simonmar
Subscribers: RyanGlScott, mpickering, angerman, thomie
Differential Revision: https://phabricator.haskell.org/D2826
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add prettyprinter tests, which take a file, parse it, pretty print it,
re-parse the pretty printed version and then compare the original and
new ASTs (ignoring locations)
Updates haddock submodule to match the AST changes.
There are three issues outstanding
1. Extra parens around a context are not reproduced. This will require an
AST change and will be done in a separate patch.
2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
to prevent noise in the output.
I am not sure what the desired behaviour in this case is, so have left
it as before. Test Ppr047 is marked as expected fail for this.
3. Apart from in a context, the ParsedSource AST keeps all the parens from
the original source. Something is happening in the renamer to remove the
parens around visible type application, causing T12530 to fail, as the
dumped splice decl is after the renamer.
This needs to be fixed by keeping the parens, but I do not know where they
are being removed. I have amended the test to pass, by removing the parens
in the expected output.
Test Plan: ./validate
Reviewers: goldfire, mpickering, simonpj, bgamari, austin
Reviewed By: simonpj, bgamari
Subscribers: simonpj, goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2752
GHC Trac Issues: #3384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the doc targets completely not partially when disabled.
Otherwise even though we are able to build the targets but we will see
some strange errors.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings in initial support for compact regions, as described in the
ICFP 2015 paper "Efficient Communication and Collection with Compact
Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni
Campagna.
Some things may change before the 8.2 release, but I (Simon M.) wanted
to get the main patch committed so that we can iterate.
What documentation there is is in the Data.Compact module in the new
compact package. We'll need to extend and polish the documentation
before the release.
Test Plan:
validate
(new test cases included)
Reviewers: ezyang, simonmar, hvr, bgamari, austin
Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1264
GHC Trac Issues: #11493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a new package, `ghc-boot-th`, to contain the `Extension`
type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
the transitive dependency set of the `template-haskell` package remains
minimal.
The `GHC.LanguageExtensions.Type` module is also re-exported by
`ghc-boot`, which provides an orphan `binary` instance as well.
Test Plan: Validate
Reviewers: goldfire, thomie, hvr, austin
Reviewed By: thomie
Subscribers: RyanGlScott, thomie, erikd, ezyang
Differential Revision: https://phabricator.haskell.org/D2224
|
|
|
|
|
| |
Previously the `_static` and `_sources` directories were installed in
the wrong parents. See #11803
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: GREP_OPTIONS=--blah ./validate
Reviewers: austin, thomie
Reviewed By: thomie
Differential Revision: https://phabricator.haskell.org/D1887
GHC Trac Issues: #11530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When CrossCompiling=YES or Stage1Only=YES, building the haddocks and the
User's Guide should be skipped, because haddock and mkUserGuidePart
depend on the GHC API.
See Note [No stage2 packages when CrossCompiling or Stage1Only] for
details.
There are several places in the build system where the variables
HADDOCK_DOCS and BUILD_SPHINX_* are checked. Instead of also checking
for the variables CrossCompiling or Stage1Only in all those places,
`make` will now exit with a nice error message when the user requests
the impossible.
Reviewers: rwbarton, austin, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is a step towards building a Linux to Windows cross-compiler.
Test Plan: Build on Linux and Windows
Reviewers: bgamari, hvr, austin, Phyx
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1758
GHC Trac Issues: #10070
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, with msys2, `pwd` works (as can be seen by the use of `pwd`
that slipped into the validate script), so there is really no need for
`ghc-pwd` anymore.
Test Plan: try it
Reviewers: austin, bgamari, Phyx
Reviewed By: Phyx
Subscribers: Phyx, erikd
Differential Revision: https://phabricator.haskell.org/D1731
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This was broken in 4905b83a2d448c65ccced385343d4e8124548a3b.
libraries/ghci/ghc.mk gets created by ./boot.
|
|
|
|
|
|
|
|
| |
Useful for testing 'make binary-dist-prep' when HADDOCK_DOCS=NO.
Reviewed by: bgamari
Differential Revision: https://phabricator.haskell.org/D1648
|
|
|
|
|
|
|
|
|
| |
This follows a similar change in
4905b83a2d448c65ccced385343d4e8124548a3b, where binaries are installed
in libexecdir/bin instead of libexecdir.
This fixes a problem with ghc not able to find ghc-split, when
SplitObjs=YES.
|
|
|
|
|
|
|
| |
LibFFI.hsc was moved to libraries/ghci/GHCi/FFI.hsc, I just forgot to
remove the old one. We also need an explicit dependency on libffi,
which moves from compiler/ghc.mk to the top-level ghc.mk (because
libraries/ghci/ghc.mk is auto-generated).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 fixes `for`-loops introduced via
64761ce9a899954a12d8e3ae8b400c5ad9648137
which can result in `for i in ;` which some
`/bin/sh` implementations don't like.
|