| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.
This substitution is classified as follows:
1. Automated substitution using sed with Ben's mapping rule [1]
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
2. Manual substitution for URLs containing `#` index
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
3. Manual substitution for strings starting with `Commentary`
Old: Commentary/XxxYyy...
New: commentary/xxx-yyy...
See also !539
[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The splitter is an evil Perl script that processes assembler code.
Its job can be done better by the linker's --gc-sections flag. GHC
passes this flag to the linker whenever -split-sections is passed on
the command line.
This is based on @DemiMarie's D2768.
Fixes Trac #11315
Fixes Trac #9832
Fixes Trac #8964
Fixes Trac #8685
Fixes Trac #8629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds top-level configure flags '--with-intree-gmp' and
'--with-framework-preferred', both of which are especially relevant
on MacOS.
Besides gaining two new flags, Hadrian also had to be taught what to
do with the 'framework' in .cabal files.
Test Plan:
./boot && ./configure --with-intree-gmp && ./hadrian/build.sh
./boot && ./configure --with-gmp-framework-preferred && ./hadrian/build.sh # on macos
Reviewers: carter, snowleopard, alpmestan, hvr, goldfire, bgamari
Subscribers: rwbarton, erikd
GHC Trac Issues: #16001
Differential Revision: https://phabricator.haskell.org/D5417
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
https://phabricator.haskell.org/D5169 built libghci for both vanilla way
and profiling way. We need to include both in the bindist list so they
will be installed.
Test Plan:
```
$ grep '^BuildFlavour' mk/build.mk
BuildFlavour=perf
$ make test_bindist
$ grep HSghc-prim bindist-list.uniq
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3.a
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3-ghc8.7.20190101.so
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a
```
|
|
|
|
|
|
|
|
|
|
| |
Currently build logs from GitLab CI around around 7 megabytes each. Of this,
around 2 megabytes is latex output. This is quite silly as essentially all of
this output is unresolved references in the early latex iterations.
Here we silence this output.
However, to make sure that we don't silence errors we allow each xelatex
invocation besides the last to fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We do this for vanilla way already.
Let's also merge sections for profiling way and use it instead of the .a
library when it exists.
Test Plan:
```
$ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter
GHCi, version 8.7.20180921: http://www.haskell.org/ghc/ :? for help
Prelude> pid <- System.Posix.Process.getProcessID
Prelude> maps <- readFile $ "/proc/" ++ show pid ++ "/maps"
Prelude> pid
3807346
Prelude> putStrLn $ unlines $ take 20 $ lines maps
00400000-02103000 r-xp 00000000 00:1a 199277344
/data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof
02104000-02106000 r--p 01d03000 00:1a 199277344
/data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof
02106000-02417000 rw-p 01d05000 00:1a 199277344
/data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof
02417000-0280a000 rw-p 00000000 00:00 0
[heap]
40098000-400b0000 rwxp 000d2000 00:1a 199276023
/data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o
400b7000-400d8000 rwxp 00000000 00:00 0
401d1000-401d2000 rwxp 000e9000 00:1a 199276023
/data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o
40415000-40419000 rwxp 0000b000 00:1a 199275165
/data/users/watashi/ghc/libraries/deepseq/dist-install/build/HSdeepseq-1.4.4.0.p_o
404f8000-40526000 rwxp 000af000 00:1a 199274234
/data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o
```
Reviewers: simonmar, bgamari, austin, hvr
Reviewed By: simonmar
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie`
files (see the wiki page:
https://ghc.haskell.org/trac/ghc/wiki/HIEFiles).
This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for
his GSOC project, as posted here:
https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d.
Test Plan: ./validate
Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi
Reviewed By: alanz, sjakobi
Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter
Differential Revision: https://phabricator.haskell.org/D5239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Requires some ghc-cabal changes as well.
Test Plan: ./validate
Reviewers: hvr, bgamari
Reviewed By: bgamari
Subscribers: hsyl20, erikd, alpmestan, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4453
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ld.gold is buggy when using -r and a linker script. See upstream bug
https://sourceware.org/bugzilla/show_bug.cgi?id=22266
This has been causing various brokenness for the GHC runtime linker,
where we load these broken object files.
Test Plan: Test program from #14675
Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14328, #14675, #14291
Differential Revision: https://phabricator.haskell.org/D4431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By request of @alexbiehl.
CCing @snowleopard and @alpmestan as the same should be done in Hadrian.
Bumps haddock submodule.
Reviewers: alexbiehl
Reviewed By: alexbiehl
Subscribers: rwbarton, thomie, carter, snowleopard, alpmestan, alexbiehl
Differential Revision: https://phabricator.haskell.org/D4365
|
|
|
|
|
| |
Do not use $SHELL as $SHELL is the user's preferred interactive shell.
We do not want this to leak into the wrapper scripts.
|
|
|
|
|
|
| |
This isn't needed anymore as we don't support GHC < 8 anymore.
This is a follow-up to 122f183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Initial implementation of split-section on Windows.
This also corrects section namings and uses the platform
convention of `$` instead of `.` to separate sections.
Implementation is based on @awson's patches to binutils.
Binutils requires some extra help when compiling the libraries
for GHCi usage. We drop the `-T` and use implicit scripts to amend
the linker scripts instead of replacing it.
Because of these very large GHCi object files, we need big-obj support,
which will be added by another patch.
Test Plan: ./validate
Reviewers: awson, austin, bgamari
Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force
GHC Trac Issues: #12913
Differential Revision: https://phabricator.haskell.org/D3383
|
|
|
|
|
|
|
|
|
|
|
| |
terminfo no longer needs to be able to find the ncurses headers.
See https://github.com/judah/terminfo/pull/22.
Reviewers: austin, hvr
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the regressions in the haddock performance tests introduced
in c9eb4385aad248118650725b7b699bb97ee21c0d.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #13789
Differential Revision: https://phabricator.haskell.org/D3629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes it's handy to change a compiler flag
for a library in stage{0,1,2}.
Usage example:
libraries/binary_EXTRA_HC_OPTS += -O1
libraries/containers_EXTRA_HC_OPTS += -O1
libraries/bytestring_EXTRA_HC_OPTS += -O1
Here override default -O2 defined in .cabal files
for these libraries to speed build up.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build failure when cross-compiling from
linux to windows looks like:
HC [stage 1] ghc/stage2/build/tmp/ghc-stage2.exe
Call hs_init_ghc() from your main() function to set these options.
/usr/libexec/gcc/i686-w64-mingw32/ld: cannot find -lHSghc-8.3-0
Similar to commit 745032dd02da511067c2939259ed212852187e0f
("rts: tweak cross-compilation to mingw32") decision to split
stage2 should be done based based on TargetOS, not HostOS.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the introduction of -split-sections, using GHCi with the RTS
linker is really slow:
```
$ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter)
GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help
Prelude> Leaving GHCi.
real 0m3.793s
```
(when we use `-fexternal-interpreter` it uses the RTS linker by default,
you can make it use the system linker by adding `-dynamic`)
Building the GHCi libs doesn't take much time or space in the GHC build,
but makes things much quicker for people using the RTS linker:
```
$ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter)
GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help
Prelude> Leaving GHCi.
real 0m0.285s
```
So I propose that we build and ship them unconditionally.
Test Plan: validate, perf tests above
Reviewers: bgamari, austin, niteria, erikd, Phyx
Reviewed By: bgamari
Subscribers: rwbarton, thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After commit a50082c11 we use -ffunction-sections -fdata-sections
for all C compilations, when $1_$2_SplitSections is set. But that
variable was set in build-package.mk which is not run for the RTS.
As a result the RTS was not being split, leading to larger binaries.
This commit fixes RTS splitting by moving the definition of
$1_$2_SplitSections to distdir-opts.mk, which is run for the RTS
(and also from build-package.mk).
Test Plan:
manual ./validate and check that RTS and base .c files
are split, but not object files in the compiler
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, snowleopard, olsner
Differential Revision: https://phabricator.haskell.org/D3137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this was added only to the RTS's C files (those are the bulk
of it though), but there are C bits in ghc-prim, integer-gmp and base
too.
Followup for #8405, allows the large table of character properties in
base to be stripped when not used.
Test Plan: validate
Reviewers: austin, bgamari, simonmar
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default ghc-pkg is quite noisy as it can't find interface files.
Test Plan:
Look at the build log stderr and see if there are lots of "cannot find
any of" errors.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is two types of options passed directly to 'ld'
(and not to 'gcc' driver):
- CONF_LD_LINKER_OPTS_STAGE$4
- EXTRA_LD_OPTS
This changedoes two things:
- split 'EXTRA_LD_OPTS' into two variables:
- EXTRA_LD_OPTS (accepts 'gcc' wrapper options)
- EXTRA_LD_LINKER_OPTS (accepts raw 'ld' options)
- wraps all LD_LINKER options as '-Wl,' when passed
to 'gcc' driver.
Fixes https://phabricator.haskell.org/D2776
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts f48f5a9ebf384e1e157b7b413e1d779f4289ddd2
The prefixing does not work as comma
is stripped by $(addprefix) macro:
The following call
$$(addprefix -optl-Wl, $$($1_$2_$3_ALL_LD_OPTS))
prefixes options with "-optl-Wl" not with "-optl-Wl,"
The simplest breakage can be seen by adding
SRC_LD_OPTS += -O1
to mk/build.mk:
<no location info>: error:
Warning: Couldn't figure out linker information!
Make sure you're using GNU ld, GNU gold
or the built in OS X linker, etc.
gcc: error: unrecognized command line option '-Wl-O1'
Another problem with original change is loss of ability
to pass options to gcc as a linker driver, for example:
SRC_LD_OPTS += -flto
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC uses gcc, not ld, for linking. Consequently all flags to be
interpreted by ld need to be prefixed by -optl,-Wl on the GHC command
line.
Test Plan: Validate on OpenBSD
Reviewers: austin, rwbarton
Reviewed By: rwbarton
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: GHC CI
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: snowleopard, thomie
Maniphest Tasks: T74
Differential Revision: https://phabricator.haskell.org/D2732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that artifacts built with build-prog see these options.
Also spruce up comments.
Test Plan: Carefully read it.
Reviewers: austin, hvr, erikd
Reviewed By: erikd
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D2673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This omits -L and -l flags from the linker command line that shouldn't
be necessary because GHC will already add them via the -package-id
flags we pass.
This also reverts part of 90538d86af579595987826cd893828d6f379f35a
that rearranges the linker command line and causes some knock-on
problems (see D2618).
Test Plan: validate (need to validate on Windows too)
Reviewers: Phyx, bgamari, niteria, austin, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2639
GHC Trac Issues: #12738
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this was a relative path which worked in the GHC tree, but
failed elsewhere. This caused trouble for out-of-tree users as well as
Hadrian, which wants to move build artifacts out of the working
directory. Fixes #8040.
Test Plan: Validate
Reviewers: thomie, austin, snowleopard, hvr
Reviewed By: snowleopard, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2530
GHC Trac Issues: #8040
|
|
|
|
| |
This avoids the interactive prompt of xelatex on error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
The madness that is latex never ceases to amaze.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously programs only depended upon the direct dependencies; while I
would have thought that this would be sufficient, somehow we were
getting to the link step of building `ghc-pkg` before `ghc-boot-th` was
built (despite the fact that `ghc-boot` has a direct dependency on
`ghc-boot-th`).
See #12078.
|
|
|
|
| |
There was a missing `#`. Hadrian couldn't come soon enough.
|
|
|
|
|
| |
This may have been the cause of various build failures on FreeBSD and
Solaris.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
scheme use the `CC=...` style scheme.
The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
stage{1,2,3}, while having a separate _STAGE0 set of env-vars
denote the bootstrap-toolchain flags/programs.
This should be simpler, less confusing, and somewhat more in line with
Autoconf's idioms (allowing us to reuse more of Autoconf rather than
(re)inventing our own confusing non-standard m4 macros to do stuff that
Autoconf could almost do already for us)
Morever, expose CC_STAGE0 as a so-called "precious" variable.
So now we can better control which bootstrapping gcc is used
(by default the one used by the stage0 ghc, unless CC_STAGE0 is
overriden)
```
Some influential environment variables:
CC_STAGE0 C compiler command (bootstrap)
CC C compiler command
CFLAGS C compiler flags
...
Use these variables to override the choices made by `configure' or to
help it to find libraries and programs with nonstandard names/locations.
```
Test Plan: I've tested that cross-compiling with
`--target=powerpc-linux-gnu` still works, and tried a few variants of
settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
Reviewers: erikd, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2078
|
|
|
|
|
| |
Previously the `_static` and `_sources` directories were installed in
the wrong parents. See #11803
|
|
|
|
|
|
|
| |
This was introduced in 109a1e53287f50103e8a5b592275940b6e3dbb53
but isn't needed anymore because by now we're bootstrapping with
GHC versions which already provide "ld command" in `ghc --info`
(that field was added in GHC 7.8)
|
|
|
|
| |
This allows building ghc in '/ghc'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A small cosmetic change, but we have to do a bit of work to
actually support it:
- Cabal submodule update, so that Cabal passes us
-this-unit-id when we ask for it. This includes
a Cabal renaming to be consistent with Unit ID, which
makes ghc-pkg a bit more scrutable.
- Build system is updated to use -this-unit-id rather than
-this-package-key, to avoid deprecation warnings. Needs
a version test so I resurrected the old test we had
(sorry rwbarton!)
- I've *undeprecated* -package-name, so that we are in the same
state as GHC 7.10, since the "correct" flag will have only
entered circulation in GHC 8.0.
- I removed -package-key. Since we didn't deprecate -package-id
I think this should not cause any problems for users; they
can just change their code to use -package-id.
- The package database is indexed by UNIT IDs, not component IDs.
I updated the naming here.
- I dropped the signatures field from ExposedModule; nothing
was using it, and instantiatedWith from the package database
field.
- ghc-pkg was updated to use unit ID nomenclature, I removed
the -package-key flags but I decided not to add any new flags
for now.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: 23Skidoo, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1780
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Build then clean
Reviewers: austin, thomie
Reviewed By: thomie
Differential Revision: https://phabricator.haskell.org/D1786
GHC Trac Issues: #11433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This code was introduced in 66218d15b7c27a4a38992003bd761f60bae84b1f to
use `-package-name` for GHC 7.8, whereas GHC 7.10 needs the new
`-this-package-key` flag.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|