Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

Since !712 the `settings` file is produced by the build system instead
of autoconf. However, this introduced a subtle bug where we would fail
to rebuild the `settings` file with what we have learned from the
install-time `configure` invocation. Fix this by not packaging
`settings` in the bindist tarball. The build system will take care of
the rest.

Also fix a bug where the value of `UseLibdw` was not being persisted to
the install time `configure`.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

Now since this is generated by the build system we should ensure that it
is properly cleaned.

[skip ci]

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

This fixes a few vestigial references to `settings` left over from !655.
Fixes #16715.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

This allows it to eventually become stage-specific

Takenobu Tani authored 6 years ago and Marge Bot committed 6 years ago

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

Ben Gamari authored 6 years ago and Marge Bot committed 6 years ago

This doesn't appear to be used anywhere in the build system and it
relies on perl. Drop it.

Ben Gamari authored 6 years ago and Marge Bot committed 6 years ago

The object splitter was the last major user of perl. There remain a few
uses in nofib but we can just rely on the system's perl for this since
it's not critical to the build.

Ben Gamari authored 6 years ago and Marge Bot committed 6 years ago

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

Alec Theriault authored 6 years ago and Marge Bot committed 6 years ago

`parallel` is used in exactly one place in the GHC tree: the T2317 test.
It seems almost by accident that it is a submodule; libraries needed
only for tests should net be included as submodules (see `QuickCheck`,
`async`, `haskell98`, `regex-compat`, `utf8-string`, `vector` and more
for examples).

T2317 will now get run only when `parallel` is installed instead of
`parallel` being required for the testsuite to run.

Alec Theriault authored 6 years ago and Ben Gamari committed 6 years ago

This means that `:p` no longer leaks the implementation details of
`Integer` with `integer-simple`. The `print037` test case should
exercise all possible code paths for GHCi's code around printing
`Integer`s (both in `integer-simple` and `integer-gmp`).

`ghc` the package now also has a Cabal `integer-simple` flag (like the
`integer-gmp` one).

Herbert Valerio Riedel authored 6 years ago and Ben Gamari committed 6 years ago

This also requires adapting `ghc-pkg` to use the new Cabal parsing API
as the old ReadP-based one has finally been evicted for good.

Hadrian bit finished by: Ben Gamari <ben@smart-cactus.org>

Zejun Wu authored 6 years ago and Ben Gamari committed 6 years ago

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
```

Simon Marlow authored 6 years ago and Ben Gamari committed 6 years ago

* All the tests in tests/ghci.debugger now pass with
  -fexternal-interpreter. These tests are now run with the ghci-ext way
  in addition to the normal way so we won't break it in the future.

* I removed all the unsafeCoerce# calls from RtClosureInspect. Yay!

The main changes are:

* New messages: GetClosure and Seq.  GetClosure is a remote interface to
  GHC.Exts.Heap.getClosureData, which required Binary instances for
  various datatypes. Fortunately this wasn't too painful thanks to
  DeriveGeneric.

* No cheating by unsafeCoercing values when printing them. Now we have
  to turn the Closure representation back into the native representation
  when printing Int, Float, Double, Integer and Char. Of these, Integer
  was the most painful - we now have a dependency on integer-gmp due to
  needing access to the representation.

* Fixed a bug in rts/Heap.c - it was bogusly returning stack content as
  pointers for an AP_STACK closure.

Test Plan:
* `cd testsuite/tests/ghci.debugger && make`
* validate

Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire

Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter

GHC Trac Issues: #13184

Differential Revision: https://phabricator.haskell.org/D4955

I believe this was originally introduced to help test DPH, which is now
gone.

Moritz Angermann authored 6 years ago and Ben Gamari committed 6 years ago

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.

Test Plan: ./validate

Reviewers: bgamari, goldfire, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4436

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Poor DPH and its vectoriser have long been languishing; sadly it seems there is
little chance that the effort will be rekindled. Every few years we discuss
what to do with this mass of code and at least once we have agreed that it
should be archived on a branch and removed from `master`. Here we do just that,
eliminating heaps of dead code in the process.

Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
`primitive` submodules.

Test Plan: Validate

Reviewers: simonpj, simonmar, hvr, goldfire, alanz

Reviewed By: simonmar

Subscribers: goldfire, rwbarton, thomie, mpickering, carter

Differential Revision: https://phabricator.haskell.org/D4761

Kavon Farvardin authored 6 years ago and Ben Gamari committed 6 years ago

To resolve ticket #11295, I think it makes sense to stop hard-coding
the pass sequences used by GHC when compiling with LLVM into the
compiler
itself.

This patchset introduces a companion to the existing `llvm-targets` file
called `llvm-passes`. The passes file is a simple association list that
holds the default LLVM `opt` pass sequence used by GHC. This allows end
users to easily save their favorite optimization flags when compiling
with LLVM.

The main benefit for ticket #11295 is that when adding a custom pass
sequence, it tends to be an extremely long string that would be
unsightly in the code.

This is essentially part 1 of 2 for ticket #11295.

Test Plan: ./validate

Reviewers: bgamari, angerman

Reviewed By: angerman

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4695

patrickdoc authored 6 years ago and Ben Gamari committed 6 years ago

This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
The bits added are the C hooks into the RTS and a basic Haskell wrapper
to these C hooks. The main reason for these to be added to GHC proper
is that the code needs to be kept in sync with the closure types
defined by the RTS. It is expected that the version of HeapView shipped
with GHC will always work with that version of GHC and that extra
functionality can be layered on top with a library like ghc-heap-view
distributed via Hackage.

Test Plan: validate

Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd

Reviewed By: bgamari

Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3055

Summary:
This shims out fopen and sopen so that they use modern APIs under the hood
along with namespaced paths.

This lifts the MAX_PATH restrictions from Haskell programs and makes the new
limit ~32k.

There are only some slight caveats that have been documented.

Some utilities have not been upgraded such as lndir, since all these things are
different cabal packages I have been forced to copy the source in different places
which is less than ideal. But it's the only way to keep sdist working.

Test Plan: ./validate

Reviewers: hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #10822

Differential Revision: https://phabricator.haskell.org/D4416

See Phab:D4377 for the rationale. We will try this again.

This reverts commit 7c173b90.

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

Tobias Dammers authored 7 years ago and Ben Gamari committed 7 years ago

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 1e9f90af.

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

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 02ff7056

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.

Moritz Angermann authored 7 years ago and Ben Gamari committed 7 years ago

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

Tamar Christina authored 7 years ago and Ben Gamari committed 7 years ago

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin, hvr

Subscribers: rwbarton, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D3886

Douglas Wilson authored 7 years ago and Ben Gamari committed 7 years ago

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

Herbert Valerio Riedel authored 7 years ago and Ben Gamari committed 7 years ago

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

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

Michal Terepeta authored 7 years ago and Ben Gamari committed 7 years ago

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

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>

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

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