testsuite: Add tests for #15270

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, carter

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

Support generating HIE files

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

RTS linker: don't crash early when not finding extra-libraries

Allow GHCi to not crash when no assumed DLL is found in the standard
location.  E.g. when loading the package built "dyn" way, we may well
have the package's DLL around, and it's the system linker which loads
necessary dependencies.

Why does this (partially) fix #11042? It's because we often (and when
having packages built `dyn` way -- almost always) don't need to load
anything recorded in the `extra-libraries` stanza, since if the package
DLL exists, GHCi linker simply calls the system linker (via `dlopen`/
`LoadLibrary` APIs) to load it and doesn't bother to load package
prelinked object file (if any) or package static library.

Thus, all "regular" (with no fancy low-level package content
manipulation) packages built "dyn" way should be OK after this fix.

Reviewers: hvr, bgamari, int-index

Reviewed By: bgamari, int-index

Subscribers: Phyx, int-index, rwbarton, carter

GHC Trac Issues: #11042

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

dmdAnal: Move handling of datacon strictness to mkWWstr_one

Previously datacon strictness was accounted for when we demand analysed a case
analysis. However, this results in pessimistic demands in some cases. For
instance, consider the program (from T10482)

    data family Bar a
    data instance Bar (a, b) = BarPair !(Bar a) !(Bar b)
    newtype instance Bar Int = Bar Int

    foo :: Bar ((Int, Int), Int) -> Int -> Int
    foo f k =
      case f of
        BarPair x y -> case burble of
                          True -> case x of
                                    BarPair p q -> ...
                          False -> ...

We really should be able to assume that `p` is already evaluated since it came
from a strict field of BarPair.

However, as written the demand analyser can not conclude this since we may end
up in the False branch of the case on `burble` (which places no demand on `x`).
By accounting for the data con strictness later, applied to the demand of the
RHS, we get the strict demand signature we want.

See Note [Add demands for strict constructors] for a more comprehensive
discussion.

Test Plan: Validate

Reviewers: simonpj, osa1, goldfire

Subscribers: rwbarton, carter

GHC Trac Issues: #15696

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

PPC NCG: Generate MO_?_QuotRem for subword sizes

Handle Int*QuotRemOP and Word*QuotRemOp in PPC NCG.
Refactor common code with remainder operation.

Test Plan: validate (I validated on Linux powerpc64le and x86_64)

Reviewers: erikd, hvr, bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Support registering Plugins through the GHC API

This allows tooling using the GHC API to use plugins internally.
Hopefully this will make it possible to decouple the development of
useful plugins from (currently) kitchen-sink type tooling projects
such as ghc-mod or HIE -- at least to some extent.

Test Plan: validate

Reviewers: bgamari, mpickering

Subscribers: mpickering, alanz, rwbarton, carter

GHC Trac Issues: #15826

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

PPC NCG: Implement MachOps for smaller sizes

Generate code for MachOps with smaller than wordsize data.
Refactor conversion MachOps.

Fixes #15854

Test Plan: validate (I validated on powerpc64le and x86_64 Linux)

Reviewers: bgamari, hvr, erikd, simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15854

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

Misleading msg with qualified imports "No module named X imported"

To check whether a given module has been imported, we do the following:
From the list of all qualified names we extract the distinct module
names to a list of module names.
Then we check whether the given module name is in this list of module
names.

Test Plan: make test TEST=T14225

Reviewers: mpickering, hvr, monoidal, osa1, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #14225

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

Do not save performance test results if worktree is dirty.

Reviewers: bgamari, tdammers

Reviewed By: bgamari, tdammers

Subscribers: rwbarton, carter

GHC Trac Issues: #15924

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

Fix recompilation bug with default class methods (#15970)

If a module uses a class, then it can instantiate the class and
thereby use its default methods, so we must include the default
methods when calculating the fingerprint for the class.

Test Plan:
New unit test: driver/T15970

Before:

```
=====> T15970(normal) 1 of 1 [0, 0, 0]
cd "T15970.run" && $MAKE -s --no-print-directory T15970
Wrong exit code for T15970()(expected 0 , actual 2 )
Stdout ( T15970 ):
Makefile:13: recipe for target 'T15970' failed
Stderr ( T15970 ):
C.o:function Main_zdfTypeClassMyDataType1_info: error: undefined
reference to 'A_toTypedData2_closure'
C.o:function Main_main1_info: error: undefined reference to
'A_toTypedData2_closure'
C.o(.data+0x298): error: undefined reference to 'A_toTypedData2_closure'
C.o(.data+0x480): error: undefined reference to 'A_toTypedData2_closure'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
```

After: test passes.

Reviewers: bgamari, simonpj, erikd, watashi, afarmer

Subscribers: rwbarton, carter

GHC Trac Issues: #15970

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

Fix uninformative hp2ps error when the cmdline contains double quotes

Reapply D5346 with fix incompatible shell quoting in tests. It seems
like `$'string'` is not recognized under all test environments, so let's
avoid it in tests.

Test Plan:
```
hp2ps: "T15904".hp, line 2: integer must follow identifier
```

use new ghc and hp2ps to profile a simple program.

Reviewers: simonmar, bgamari, erikd, tdammers

Reviewed By: bgamari

Subscribers: tdammers, carter, rwbarton

GHC Trac Issues: #15904

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

cosmetic change: expandtab in utils/hp2ps/HpFile.c

rGHCbba2b9bf2d69700dc114118658507aaac34c5e62 expand tabs in
utils/hp2ps/HpFile.c with tabwidth 2, but the code was written as
tabwidth 8.  This change simply retabs the code with tabwidth 8 and
removes trailing spaces.

Test Plan: Tested in stacked diff: {D5388}

Reviewers: simonmar, bgamari, afarmer, tdammers

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

circleci: ignore gitlab branches for all jobs in the validate workflow

Our previous attempt ended up breaking the CircleCI config, but
this one has been tested, see:

  https://circleci.com/gh/ghc/ghc/tree/alp%2Fcircleci%2Fignore-gitlab-branches

which shows the builds getting triggered correctly. I also pushed the same
branch under 'gitlab/alp/test', and that didn't trigger any build, as desired.

Reviewers: bgamari

Subscribers: rwbarton, carter

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

Hadrian: ability to run a subset of the testsuite

This was supposed to be working already but didn't work when we
specified several tests with --only. This patch not only fixes this
but also makes it possible to specify a subset of tests to run with the
TEST environment variable, like the make build system. Here are some
examples:

    hadrian/build.sh test --only=plugins01
    hadrian/build.sh test --only="plugins01 plugins02"
    TEST="plugins01 plugins02" hadrian/build.sh test
    TEST=plugins03 hadrian/build.sh test --only="plugins01 plugins02"

When both the TEST environment variable and the --only flag are used,
we simply concatenate the list of tests from both sources and ask the
testsuite driver to run them all.

This patch addresses #16026.

Test Plan: hadrian/build.sh test --only="plugins01 plugins02"

Reviewers: bgamari, snowleopard

Reviewed By: bgamari, snowleopard

Subscribers: rwbarton, carter

GHC Trac Issues: #16026

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

Hadrian: simple targets for building libraries and executables

This patch introduces (phony) build targets of the form

    (1) stage<N>:<lib>:<name>   (e.g: stage1:lib:Cabal)
    (2) stage<N>:<exe>:<name>   (e.g: stage2:exe:ghc-bin)

where (1) builds the given library with the stage N compiler and (2)
builds the given executable with the stage N-1 compiler. This patch may
be generating too many such targets but it's a first stab that we can
refine.

This fixes #15949.

Test Plan: hadrian/build.sh stage1:exe:ghc-bin

Reviewers: bgamari, snowleopard

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15949

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

configure: Don't use ln -v

There's no reason why we need to print the linked files and apparently
ln on OpenBSD doesn't support -v.

Fixes #15946.

Test Plan: Validate

Reviewers: monoidal

Reviewed By: monoidal

Subscribers: rwbarton, erikd, carter

GHC Trac Issues: #15946

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

Add +RTS -F to the --help output

Test Plan: `./inplace/bin/ghc-stage2 +RTS --help"

Reviewers: bgamari, sgraf, erikd

Reviewed By: sgraf

Subscribers: adamse, rwbarton, carter

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

Revert dynamically linking ghc.

Building a dynamically linked ghc is broken do to incorrectly building
and installing libffi. This disables building a dynamically linked ghc
and ghc-iserv-dyn while keeping most of the code in the relevant
commits: 79d5427e1 and 89fa34ecd

Test Plan:
Ensure build environment does NOT have a system libffi installed (you
may want to use a nix environment).
Then `hadrian/build.sh -c --flavour=default`.

Reviewers: bgamari, alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, carter

GHC Trac Issues: #15837

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

circleci: Add integer-simple build target

Fixes #15915.

testsuite: Mark tickets identified in #15467 as broken

rts: Disable fallthrough attribute when compiling with Clang

Apparently clang doesn't enable implicitly fallthrough warnings by default
http://llvm.org/viewvc/llvm-project?revision=167655&view=revision when compiling
C and the attribute cause warnings of their own (#16019).

utils/gen-dll: Bump containers upper bound

Fixes #16023.

CircleCI: Add configurations for Centos 7 and Debian 9

testsuite: Use explicit -e in sed command

Otherwise Darwin's sed interprets the command as the suffix for -i.

Fix #16008 with a pinch of addConsistencyConstraints

Summary:
#16008 happened because we forgot to typecheck nullary
associated type family instances in a way that's consistent with the
type variables bound by the parent class. Oops. Easily fixed with a
use of `checkConsistencyConstraints`.

Test Plan: make test TEST=T16008

Reviewers: simonpj, goldfire, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, carter

GHC Trac Issues: #16008

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

Fix minor mistake in comment about data decls.

Fixes #16024. [skip ci]

hadrian: Drop nix build script

It's currently too out-of-date to build current hadrian and is arguably
completely broken anyways (see #15794).

testsuite: 32-bit expected output for T15460

rts: Ensure that task->id is initialized

Reviewers: erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

Use --no-as-needed with LLD too

Test Plan: validate using LLD as the linker (TODO)

Reviewers: bgamari, angerman, kavon, erikd

Reviewed By: bgamari

Subscribers: watashi, rwbarton, carter

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

Add -fno-safe-haskell flag

This flag can be set to turn off the Safe Haskell checks.

Whether a module is marked Safe/Unsafe/Trustworthy is ignored when
this flag to set.

Reviewers: bgamari, tdammers

Reviewed By: tdammers

Subscribers: rwbarton, carter

GHC Trac Issues: #15920

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

Fix StgLint bound id check, generalize StgLint

StgLint was incorrectly using isLocalId for bound id check to see
whether an id is imported (in which case we don't expect it to be bound)
or local.  The problem with isLocalId is that its semantics changes
after Core, as explained in the note: (last line)

    Note [GlobalId/LocalId]
    ~~~~~~~~~~~~~~~~~~~~~~~
    A GlobalId is
      * always a constant (top-level)
      * imported, or data constructor, or primop, or record selector
      * has a Unique that is globally unique across the whole
        GHC invocation (a single invocation may compile multiple
        modules)
      * never treated as a candidate by the free-variable finder;
            it's a constant!

    A LocalId is
      * bound within an expression (lambda, case, local let(rec))
      * or defined at top level in the module being compiled
      * always treated as a candidate by the free-variable finder

    After CoreTidy, top-level LocalIds are turned into GlobalIds

We now pass current module as a parameter to StgLint, which uses it to
see if an id should be bound (defined in the current module) or not
(imported).

Other changes:

- Generalized StgLint to make it work on both StgTopBinding and
  CgStgTopBinding.
- Bring all top-level binders into scope before linting top-level
  bindings to allow uses before definitions.

TODO: We should remove the binder from local vars when checking RHSs of
non-recursive bindings.

Test Plan: This validates.

Reviewers: simonpj, bgamari, sgraf

Reviewed By: simonpj, sgraf

Subscribers: rwbarton, carter

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

Fix #15369: GHCi doesn't honor :set +c when loading for a second time

The decision to (re)collect the type info for a (re)loaded module is
now taken only by comparing the file timestamps of the .hs file of the
module. (Or form the .o file if the .hs file is missing).
If the file timestamp changes, we (re)collect the type info.
The timestamp of the processing time of the last collect is no longer
used.

Test Plan: make test TEST=T15369

Reviewers: alanz, hvr, monoidal, osa1, thomie, bgamari, tdammers

Reviewed By: tdammers

Subscribers: rwbarton, carter

GHC Trac Issues: #15369

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

Add haddock for Node in Digraph. [skip ci]

Test Plan: make

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Remove redundant include of Rts.h in EventLogWriter.h

`EventLogWriter.h` doesn't use anything from `Rts.h`, the include is
redundant. This include is ignored when we include

```
Rts.h -> RtsAPI.h -> rts/EventLogWriter.h -> Rts.h
```

but can can cause problem when we include `RtsApi.h` directly with
errors like

```
In file included from /usr/lib/ghc-8.6.2/include/RtsAPI.h:20:
In file included from
/usr/lib/ghc-8.6.2/include/rts/EventLogWriter.h:14:
In file included from /usr/lib/ghc-8.6.2/include/Rts.h:185:
/usr/lib/ghc-8.6.2/include/rts/storage/GC.h:187:29: error: unknown type
name 'Capability'
StgPtr  allocate          ( Capability *cap, W_ n );
```

Test Plan: ./validate

Reviewers: simonmar, bgamari, afarmer, erikd, alexbiehl

Reviewed By: bgamari, alexbiehl

Subscribers: rwbarton, carter

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

Rename "changed" to "no-change" in HscMain

hscSimpleIface is returning a bool for whether there were _no changes_
in the iface file. The same bool is called "no_change_at_all" in
mkIface_, and "no_change" in hscWriteIface and other functions. However
it is called "changed" in HscMain.finish and hscMaybeWriteIface, which
is confusing because "changed" and "no_change" have opposite meanings.
This patch renames "changed" to "no_change" to fix this.

Reviewers: simonpj, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Hadrian: fix dynamicGhcPrograms value for the quickest flavour

Quickest does not build anything in a dynamic way, so that
flavour should default to not building "ghc programs" dynamically.

I ran into this problem by building the 'docs' target with quickest,
which failed because at some point we run a haddock command in a
context whose Way is sensitive to dynamicGhcPrograms, and it
started looking for dyn interface files when it shouldn't have.

Test Plan: hadrian/build.sh --flavour=quickest docs

Reviewers: snowleopard, bgamari

Reviewed By: snowleopard

Subscribers: rwbarton, carter

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

Mark SRT_1/SRT_2 as CONSTR_1_0/CONSTR_2_0

Test Plan:
Validated locally, but skipped perf tests as there's a
framework-related error
there.

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

hadrian: eliminate most of the remaining big rule enumerations

Following what was done to Rules.Library some time ago and to
Rules.Compile recently (D5412), this patch moves more rules away from
the "enumerate a lot of contexts and generate one rule for each" style
and instead uses the "parse data from file path to recover context"
approach. In fact, the only rules left to convert seem to be the ones
from Rules.Generate.

This effectively decreases the pauses described in #15938 further as
well as the amount of allocations and GC that we do, unsurprisingly.
Nowhere as drastically as D5412, though.

Test Plan: perform full build and generate docs

Reviewers: snowleopard, bgamari

Reviewed By: snowleopard

Subscribers: rwbarton, carter

GHC Trac Issues: #15938

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

Require 'libdw' for '--enable-dwarf-unwind'

This causes './configure --enable-dwarf-unwind' to exit with a helpful
error message when 'libdw' cannot be found (compared to the previous
behaviour of silently pretending the user hadn't requested DWARF support
at all).

Test Plan: ./configure --enable-dwarf-unwind # on systems with/without
libdw

Reviewers: bgamari, nh2

Reviewed By: nh2

Subscribers: nh2, rwbarton, erikd, carter

GHC Trac Issues: #15968

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

Mark broken tests on powerpc64le and skip ghci-ext

Mark tests with DWARF as broken
Test way `ghci-ext` only where available

Test Plan: validate

Reviewers: bgamari, hvr, simonmar, erikd, Phyx

Reviewed By: bgamari, Phyx

Subscribers: Phyx, rwbarton, carter

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

testsuite: Fix tests expecting 64-bit word size

These were added in 75a8349b2a7d0142d3d687837caf5a95bbb4368d.

Add missing space in report_summary output

Fixed plugin example to work

Fix typo in Foldable docs

Add some complexities to Data.List documentation (#15003)

Namely for:
- head
- uncons
- tail
- last
- init
- null

CircleCI: Don't ignore gitlab/.* branches

This was added (for good reasons) in b9260e925e998f715865ae043bdb9f779ab5f849
but it seems this field isn't allowed in this context. Sadly there doesn't
appear to be an easy way to accomplish what we are after with CircleCI's rather
restrictive configuration language. Sigh.

testsuite: Fix use of stats_num_field

This is now collect_stats.

Fix #12102/#15872 by removing outdated users' guide prose

Summary:
In the beginning, #12102 (and #15872, which is of a similar
ilk) were caused by a poor, confused user trying to use code that
looks like this (with a constraint in the kind of a data type):

```lang=haskell
type family IsTypeLit a where
  IsTypeLit Nat    = 'True
  IsTypeLit Symbol = 'True
  IsTypeLit a      = 'False

data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where
  MkNat    :: T 42
  MkSymbol :: T "Don't panic!"
```

Many bizarre GHC quirks (documented in those tickets) arose from
this sort of construction. Ultimately, the use of constraints in
data type kinds like this has made a lot of people very confused and
been widely regarded as a bad move.

Commit 2257a86daa72db382eb927df12a718669d5491f8 finally put this
feature out of its misery, so now the code above simply errors with
`Illegal constraint in a kind`. As a result, the aforementioned
tickets are moot, so this patch wraps a bow on the whole thing by:

1. Removing the (now outdated) section on constraints in data type
   kinds from the users' guide, and
2. Adding a test case to test this code path.

Test Plan: make test TEST=T12102

Reviewers: goldfire, simonpj, bgamari, tdammers

Reviewed By: tdammers

Subscribers: tdammers, rwbarton, carter

GHC Trac Issues: #12102, #15872

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

Careful tweaking to exprOkForSpeculation

This patch does several things:

* Make exprOkForSpeculation ignore evaluatedness of variables
  See the Note [exprOkForSpeculation and evaluated variables]
  This means that the binder-swap transformation no longer
  invaliates the let/app invariant.

* Make exprOkForSpeculation return False for
     DataToTagOp and SeqOp.
  See Note [exprOkForSpeculation and SeqOp/DataToTagOp]

* Remove the 'can_fail' property from dataToTag#; it was
  always a hack (described in the old Note [dataToTag#] in
  primops.txt.pp), and now its not necessary because of the
  fixes above.

* Make SetLevels use exprIsHNF, /not/ exprOkForSpeculation,
  when floating single-alternative cases.  See SetLevels
  Note [Floating single-alternative cases]

* Fix a buglet in FloatIn; probably never bites in practice
  See Note [Dead bindings]

Collectively, these changes finally fix Trac #15696.

Wibble to Taming the Kind Inference Monster

I had allowed rename/should_fail/T15828 (Trac #15828) to regress a bit.
The main payload of this patch is to fix that problem, at the cost of
more contortions in checkConsistentFamInst.  Oh well, at least they are
highly localised.

I also update the -ddump-types code in TcRnDriver to print out some
more expicit information about each type constructor, thus instead of

   DF{3} :: forall k. * -> k -> *

we get

   data family DF{3} :: forall k. * -> k -> *

Remember, this is debug-printing only.  This change is the reason
that so many .stderr files change.

hadrian: optimise Rules.Compile

Previously, as reported in #15938, resuming a build "in the middle",
e.g when building _build/stage1/libraries/base/, hadrian would take up
to a whole minute to get started doing actual work, building code.

This was mostly due to a big enumeration that we do in Rules.hs, to
generate all the possible patterns for object files for 1) all ways, 2)
all packages and 3) all stages. Since rule enumeration is always
performed, whatever the target, we were always paying this cost, which
seemed to grow bigger the farther in the build we stopped and were
resuming from.

Instead, this patch borrows the approach that we took for Rules.Library
in https://github.com/snowleopard/hadrian/pull/571, which exposes all the
relevant object files under as few catch-all rules as possible (8 here),
and parses all the information we need out of the object's path.

The concrete effect of this patch that I have observed is to reduce the
45-60 seconds pause to <5 seconds. Along with the Shake performance
improvements that Neil mentions in #15938, most of the pause should
effectively disappear.

Reviewers: snowleopard, bgamari, goldfire

Reviewed By: snowleopard

Subscribers: rwbarton, carter

GHC Trac Issues: #15938

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

Add fusion rules for the zipWith functions in base (#15263)

This patch will allow `zip3` and `zipWith3` in `GHC.List` as well
as `zipWith4`, `zipWith5`, `zipWith6` and `zipWith7` in `Data.OldList` to fuse.

These rules are kept in a similar style as the rules for `zip` and `zipWith`.

Added a corresponding test case.

Test Plan: validate

Reviewers: hvr, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rockbmb, rwbarton, carter

GHC Trac Issues: #15263

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

Windows: Use the "big" PE object format on amd64

Test Plan: Do full build on Windows.

Reviewers: AndreasK, Phyx

Reviewed By: AndreasK

Subscribers: rwbarton, erikd, carter

GHC Trac Issues: #15934

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

Don't use a generic apply thunk for known calls

Summary:
Currently, an AP thunk like `sat = f a b c` will not have its own entry
point and info pointer and will instead reuse a generic apply thunk
like `stg_ap_4_upd`.

That's great from a code size perspective, but if `f` is a known
function, a specialised entry point with a plain call can be much faster
than figuring out the arity and doing dynamic dispatch.

This looks at `f`s arity to figure out if it is a known function and if so, it
will not lower it to a generic apply function.

Benchmark results are encouraging: No changes to allocation, but 0.2% less
counted instructions.

Test Plan: Validates locally

Reviewers: simonmar, osa1, simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #16005

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

Remove a tcTrace

This tcTrace, in tcTyFamInstEqn, caused a knot-tying loop, because
it was printing a type after zonking-to-Type.  Easy solution: don't
do that.

Tests Trac #14847

Remove explicit recursion in retainer profiling (fixes #14758)

Retainer profiling contained a recursion that under
certain circumstances could lead to the stack overflow
in C code.

The idea of the improvement is to keep an explicit stack for the
object, more precise to reuse existing stack, but allow new type of
objects to be stored there.

There is no reliable reproducer that is not a big program
but in some cases foldr (+) 0 [1..10000000] can work.

Reviewers: bgamari, simonmar, erikd, osa1

Reviewed By: bgamari, osa1

Subscribers: osa1, rwbarton, carter

GHC Trac Issues: #14758

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

Remove duplicates in -ddump-minimial-imports

This fixes Trac #15994.

Previously RdrName.gresToAvailInfo assumed that the input list
of GREs had no duplicates. I accidentally broke this precondition
in this refactoring:

    commit 6353efc7694ba8ec86c091918e02595662169ae2
    Date:   Thu Nov 22 14:48:05 2018 -0500

    Fix unused-import warnings

    This patch fixes a fairly long-standing bug (dating back to 2015) in
    RdrName.bestImport, namely

(There was an ASSERT, but it's usually switched off in stage2.  It
tripped when I switched stage2 assertions on.)

The fix is straightforward: account for dups in gresToAvailInfo.

linker: store entire link map and use it.

Summary:
This fixes a corner case in which we have seen the symbol multiple times in
different static libraries, but due to a depencency we end up loading the
symbol from a library other than the first one.

Previously the runtime linker would only track symbols from the first
library and did not store the full link map.  In this case it was unable
to find the address for the symbols in the second library during delay
loading.

This change stores the address of all symbols seen so a full link map
is generated, such that when we make a different decision later than what
was expected we're able to still correctly load the library.

Test Plan: ./validate, new testcase T15894

Reviewers: angerman, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15894

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

Hadrian: include 'findPtr' via find-ptr cabal flag

Summary:
This is the latest in the 'findPtr' saga. See

  * 900c47f88784b91517c00be3e1087322e62f698e
  * 561748cb507505bd5b7bd76bdc57796d896b62a2

for the previous attempts. The problem with re-using the 'debug'
cabal flag for the purpose of forcing inclusion of 'findPtr' occurs
when 'debug' is one of the RTS ways, but RTS is not being compiled
with '-DDEBUG':

  * the 'debug' flag gets passed to cabal, signalling to build
    'rts' with the debug flavour, but also forcing inclusion of
    the 'findPtr'/'_findPtr' symbol

  * since '-DDEBUG' isn't enabled, that symbol doesn't show up in
    the libraries, so executable that depend on 'rts' (everything)
    will end up always requiring 'findPtr'/'_findPtr' but 'rts' won'y
    provide it!

The fix is simple: create a a new 'find-ptr' cabal-flag whose only
purpose is forcing '-Wl,-u,findPtr'/'-Wl,-u,_findPtr'. Then, enable that
flag when the RTS is being compiled with '-DDEBUG'

Test Plan: ./hadrian/build.sh -c # on mac

Reviewers: alpmestan, snowleopard, bgamari, erikd, simonmar, Phyx

Reviewed By: alpmestan, snowleopard, Phyx

Subscribers: Phyx, rwbarton, carter

GHC Trac Issues: #15956

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

Improve test T14452 for Windows

Summary: Under Windows all parameters to gcc are enclosed in quotes, opposite to
Linux, where the quotes are missing. Therefore in the test, we remove all
quotes in the stdout file with sed.

Test Plan: make test TEST=T14452

Reviewers: osa1, hvr, bgamari, monoidal, Phyx, simonpj

Reviewed By: Phyx

Subscribers: rwbarton, carter

GHC Trac Issues: #14452

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

Bump nofib submodule

Test Plan: run nofib

Reviewers: bgamari, tdammers

Reviewed By: tdammers

Subscribers: rwbarton, carter

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

Fix link name to a note

Reviewers: goldfire, bgamari, tdammers

Reviewed By: tdammers

Subscribers: rwbarton, carter

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

Add test cases for #7503, #14451

At some point between 8.4 and 8.6, two things were fixed:

* The entirety of #14451.
* One of the test cases in #7503. I've added this as T7503a. The
  other test case from that ticket still does /not/ work, so we'll
  have to add T7503b some other day.

Comments only

Introduce tcTypeKind, and use it

In the type checker Constraint and * are distinct; and the function
that takes the kind of a type should respect that distinction
(Trac #15971).

This patch implements the change:

* Introduce Type.tcTypeKind, and use it throughout the type
  inference engine

* Add new Note [Kinding rules for types] for the kinding
  rules, especially for foralls.

* Redefine
    isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
  (it had a much more complicated definition before)

Some miscellaneous refactoring

* Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
  in favour of TyCoRep.kindRep, kindRep_maybe

* Rename Type.getRuntimeRepFromKind_maybe
  to getRuntimeRep_maybe

I did some spot-checks on compiler perf, and it really doesn't
budge (as expected).

Fix embarrassing infinite loop in pprParendType

Summary:
`pprParendType` was missing an explicit case for
`EqualityT`, which caused it to fall through to a catch-all case
that invokes `ppr`. But `ppr` itself does not have a case for a
partial application of `EqualityT`, so //it// falls back to
`pprParendType`, resulting in an infinite loop!

The fix is simple: add a case for `EqualityT` in `pprParendType`.
While I was in the neighborhood, I removed the catch-call case in
`pprParendType` to make this sort of mistake less likely to happen
in the future.

Test Plan: make test TEST=T15985

Reviewers: bgamari, monoidal, simonpj

Reviewed By: monoidal, simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #15985

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

Fix #15954 by rejigging check_type's order

Summary:
Previously, `check_type` (which catches illegal uses of
unsaturated type synonyms without enabling `LiberalTypeSynonyms`,
among other things) always checks for uses of polytypes before
anything else. There is a problem with this plan, however:
checking for polytypes requires decomposing `forall`s and other
invisible arguments, an action which itself expands type synonyms!
Therefore, if we have something like:

```lang=haskell
type A a = Int
type B (a :: Type -> Type) = forall x. x -> x
type C = B A
```

Then when checking `B A`, `A` will get expanded to `forall x. x -> x`
before `check_type` has an opportunity to realize that `A` is an
unsaturated type synonym! This is the root cause of #15954.

This patch fixes the issue by moving the case of `check_type` that
detects polytypes to be //after// the case that checks for
`TyConApp`s. That way, the `TyConApp` case will properly flag things
like the unsaturated use of `A` in the example above before we ever
attempt to check for polytypes.

Test Plan: make test TEST=T15954

Reviewers: simonpj, bgamari, goldfire

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #15954

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

Warn on all out-of-range literals in pats/exprs

Summary:
These changes were motivated by #13256. While poking around, I
realized we weren't very consistent in our "-Woverflowed-literals"
warnings. This patch fixes that by:

  * warning earlier on in the pipeline (ie. before we've desugared
    'Int' patterns into 'I# Int#')
  * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed
    literals)
  * covering more pattern / expression forms

4/6 of the warnings in the 'Overflow' test are due to this patch. The
other two are mostly for completeness.

Also fixed a missing empty-enumeration warning for 'Natural'.

This warnings were tripped up by the 'Bounded Word' instance (see #9505),
but the fix was obvious and simple: use unboxed word literals.

Test Plan: make TEST=Overflow && make TEST=T10930

Reviewers: hvr, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #13256, #10930

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

update (CicleCI) CI script to work with ghc-ci

ghc-ci is a tiny webservice that acts as an intermediate between our
CircleCI jobs on Gitlab and the actual builds running on CircleCI, so that
the build script doesn't need to rely on any secret, which makes the whole
setup fork-friendly.

The concrete effect of this patch is to allow any fork of GHC on Gitlab to
run CircleCI jobs.

Hadrian: Print all testsuite output to stdout

See https://ghc.haskell.org/trac/ghc/ticket/15951

testsuite: Don't use git status to determine whether we are inside a repo

Git status is extremely expensive for this task. We instead use `git rev-parse
HEAD` and throw away the output to ensure we don't spam the user.

Disable most Pipelines-based validation ways

Add GitLab CI

hadrian/test: Don't depend upon iserv on Windows

Iserv is not supported on Windows. This fixes #15950 but this whole situation
feels awfully fragile to me.

Add a Gitlab CI script that runs Circle CI validation jobs

And put it to use for running i386 and x86_64 linux validate,
x86_64 darwin validate and building with hadrian. For all the validate
jobs, we save the artifacts (bindist + test results for now) in Circle CI
and subsequently grab them in Gitlab. The nice side effect is that merge
requests now show the change in test results from the patches and let you
download or browse the artifacts.

Skip all performance tests if not in a git repo.

Reviewers: bgamari, tdammers, osa1

Reviewed By: tdammers

Subscribers: osa1, tdammers, rwbarton, carter

GHC Trac Issues: #15923

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

Deduplicate decision to count thunks in `-ticky`

Summary:
Previously, the logic that checks whether a thunk has a counter or not
was duplicated in multiple functions.

This led to thunk enters being accounted to their enclosing functions in
`StgCmmTicky.tickyEnterThunk`, because the outer call to
`withNewTickyCounterThunk` didn't set the counter label for the thunk.
And rightly so! `tickyEnterThunk` should only account thunk enters to a
counter if `-ticky-dyn-thunk` is on.

This patch extracts the logic that was already present in its most
general form in `withNewTickyCounterThunk` into its own functions and
lets all other call sites checking for `-ticky-dyn-thunk` call this new
function named `thunkHasCounter` instead.

Reviewers: bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

Add 'Lift' instances for 'NonEmpty' and 'Void'

Summary:
Since 'NonEmpty' and 'Void' are now part of 'base', it makes
sense that we put 'Lift' instances for them in 'template-haskell'.
Not doing so is going to force users to define their own (possibly
colliding) orphan instances downstream.

Test Plan: ./validate

Reviewers: goldfire, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #15961

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

Two tests for Trac #14230

Accept T15828 test output

This test output changed slightly due to commit
2257a86daa72db382eb927df12a718669d5491f8 (which is expected).

Add a test case for #15962

Test Plan: make test TEST=T15962

Reviewers: RyanGlScott, bgamari

Reviewed By: RyanGlScott

Subscribers: rwbarton, carter

GHC Trac Issues: #15962

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

Make ghc-in-ghci support Hadrian

Summary:
Currently, `ghc-in-ghci` is hard-coded to only support
the installation path of the `make`-based build system. There isn't
a fundamental reason why this must be the case, however—it's just a
matter of communicating which directories to look into.

For the time being, I've hacked `utils/ghc-in-ghci/run.sh` to just
check the default Hadrian installation path in addition to the `make`
one. Disclaimer: I'm not well-versed in `bash`-fu, so it's possible
that there is a better way to accomplish what I'm setting out to do.
Suggestions welcome.

Test Plan: ./utils/ghc-in-ghci/run.sh

Reviewers: alpmestan, bgamari

Reviewed By: alpmestan

Subscribers: rwbarton, carter

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

Allow containers-0.6, QuickCheck-2.12 in Hadrian

Summary:
Currently, Hadrian has restrictive upper bounds on
`containers` and `QuickCheck` that prevents it from building with
the latest versions of each respective library (0.6.0.1 and
2.12.6.1). There doesn't appear to be any good reason to do so,
since Hadrian builds fine with them, so let's bump the upper version
bounds accordingly.

Test Plan: ./build/hadrian.sh

Reviewers: bgamari, alpmestan, snowleopard

Reviewed By: snowleopard

Subscribers: rwbarton, carter

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

Fix #15953 by consistently using dumpIfSet_dyn to print debug output

Summary:
In some modules we directly dump the debugging output to STDOUT
via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file`
is enabled, that output should be written to a file. Easily fixed.

Certain tests (T3017, Roles3, T12763 etc.) expect part of the
output generated by `-ddump-types` to be in 'PprUser' style. However,
generally we want all other debugging output to use 'PprDump'
style. `traceTcRn` and `traceTcRnForUser` help us accomplish this.

This patch also documents some missing flags in the users guide.

Reviewers: RyanGlScott, bgamari, hvr

Reviewed By: RyanGlScott

Subscribers: rwbarton, carter

GHC Trac Issues: #15953

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

Add missing since annotations

Reviewers: hvr, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #15930

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

Fix #15828, from `More explicit foralls`

Summary:
Fix a bug in commit 12eeb9 which permits the following:

```
class C a where
  type T a b
instance C (Maybe a) where
  type forall a b. T (Maybe a) b = b
```

where instead, the user should write:

```
instance C (Maybe a) where
  type forall b. T (Maybe a) b = b
```

Update the users guide to discuss scoping of type variables in
explicit foralls in type family instances.

Test Plan: validate

Reviewers: bgamari, goldfire, monoidal

Reviewed By: goldfire

Subscribers: monoidal, rwbarton, carter

GHC Trac Issues: #15828

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

Taming the Kind Inference Monster

My original goal was (Trac #15809) to move towards using level numbers
as the basis for deciding which type variables to generalise, rather
than searching for the free varaibles of the environment.  However
it has turned into a truly major refactoring of the kind inference
engine.

Let's deal with the level-numbers part first:

* Augment quantifyTyVars to calculate the type variables to
  quantify using level numbers, and compare the result with
  the existing approach.  That is; no change in behaviour,
  just a WARNing if the two approaches give different answers.

* To do this I had to get the level number right when calling
  quantifyTyVars, and this entailed a bit of care, especially
  in the code for kind-checking type declarations.

* However, on the way I was able to eliminate or simplify
  a number of calls to solveEqualities.

This work is incomplete: I'm not /using/ level numbers yet.
When I subsequently get rid of any remaining WARNings in
quantifyTyVars, that the level-number answers differ from
the current answers, then I can rip out the current
"free vars of the environment" stuff.

Anyway, this led me into deep dive into kind inference for type and
class declarations, which is an increasingly soggy part of GHC.
Richard already did some good work recently in

   commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3
   Date:   Thu Sep 13 09:56:02 2018 +0200

    Finish fix for #14880.

    The real change that fixes the ticket is described in
    Note [Naughty quantification candidates] in TcMType.

but I kept turning over stones. So this patch has ended up
with a pretty significant refactoring of that code too.

Kind inference for types and classes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Major refactoring in the way we generalise the inferred kind of
  a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
  function, generaliseTcTyCon.  Plus a new Note to explain it
  Note [Inferring kinds for type declarations].

* We decided (Trac #15592) not to treat class type variables specially
  when dealing with Inferred/Specified/Required for associated types.
  That simplifies things quite a bit. I also rewrote
  Note [Required, Specified, and Inferred for types]

* Major refactoring of the crucial function kcLHsQTyVars:
  I split it into
       kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
  because the two are really quite different. The CUSK case is
  almost entirely rewritten, and is much easier because of our new
  decision not to treat the class variables specially

* I moved all the error checks from tcTyClTyVars (which was a bizarre
  place for it) into generaliseTcTyCon and/or the CUSK case of
  kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.

* I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
  now there is no difference between tcImplicitTKBndrs and
  kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
  Same for kc/tcExplicitTKBndrs.  None of them monkey with level
  numbers, nor build implication constraints.  scopeTyVars is gone
  entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.

  I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
  the bnew bindExplicitTKBndrs.

Quantification
~~~~~~~~~~~~~~
* I now deal with the "naughty quantification candidates"
  of the previous patch in candidateQTyVars, rather than in
  quantifyTyVars; see Note [Naughty quantification candidates]
  in TcMType.

  I also killed off closeOverKindsCQTvs in favour of the same
  strategy that we use for tyCoVarsOfType: namely, close over kinds
  at the occurrences.

  And candidateQTyVars no longer needs a gbl_tvs argument.

* Passing the ContextKind, rather than the expected kind itself,
  to tc_hs_sig_type_and_gen makes it easy to allocate the expected
  result kind (when we are in inference mode) at the right level.

Type families
~~~~~~~~~~~~~~
* I did a major rewrite of the impenetrable tcFamTyPats. The result
  is vastly more comprehensible.

* I got rid of kcDataDefn entirely, quite a big function.

* I re-did the way that checkConsistentFamInst works, so
  that it allows alpha-renaming of invisible arguments.

* The interaction of kind signatures and family instances is tricky.
    Type families: see Note [Apparently-nullary families]
    Data families: see Note [Result kind signature for a data family instance]
                   and Note [Eta-reduction for data families]

* The consistent instantation of an associated type family is tricky.
  See Note [Checking consistent instantiation] and
      Note [Matching in the consistent-instantation check]
  in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
  when we have the relevant info to hand.

* I got tired of the compromises in etaExpandFamInst, so I did the
  job properly by adding a field cab_eta_tvs to CoAxBranch.
  See Coercion.etaExpandCoAxBranch.

tcInferApps and friends
~~~~~~~~~~~~~~~~~~~~~~~
* I got rid of the mysterious and horrible ClsInstInfo argument
  to tcInferApps, checkExpectedKindX, and various checkValid
  functions.  It was horrible!

* I got rid of [Type] result of tcInferApps.  This list was used
  only in tcFamTyPats, when checking the LHS of a type instance;
  and if there is a cast in the middle, the list is meaningless.
  So I made tcInferApps simpler, and moved the complexity
  (not much) to tcInferApps.

  Result: tcInferApps is now pretty comprehensible again.

* I refactored the many function in TcMType that instantiate skolems.

Smaller things

* I rejigged the error message in checkValidTelescope; I think it's
  quite a bit better now.

* checkValidType was not rejecting constraints in a kind signature
     forall (a :: Eq b => blah). blah2
  That led to further errors when we then do an ambiguity check.
  So I make checkValidType reject it more aggressively.

* I killed off quantifyConDecl, instead calling kindGeneralize
  directly.

* I fixed an outright bug in tyCoVarsOfImplic, where we were not
  colleting the tyvar of the kind of the skolems

* Renamed ClsInstInfo to AssocInstInfo, and made it into its
  own data type

* Some fiddling around with pretty-printing of family
  instances which was trickier than I thought.  I wanted
  wildcards to print as plain "_" in user messages, although
  they each need a unique identity in the CoAxBranch.

Some other oddments

* Refactoring around the trace messages from reportUnsolved.
* A bit of extra tc-tracing in TcHsSyn.commitFlexi

This patch fixes a raft of bugs, and includes tests for them.

 * #14887
 * #15740
 * #15764
 * #15789
 * #15804
 * #15817
 * #15870
 * #15874
 * #15881

Hadrian: support dynamically linking ghc

* (#15837 point 5) Use the -rpath gcc option and using the $ORIGIN
variable which the dynamic linker sets to the location of the ghc
binary.
* (#15837 point 4) "-fPIC -dynamic" options are used when building ghc
when either ghc or the rts have a dynamic way.
* (#15837 point 7) "-shared -dynload deploy" options are only used when
linking a library (no longer when linking a program).

Reviewers: bgamari, alpmestan

Reviewed By: alpmestan

Subscribers: adamse, rwbarton, carter

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

Hadrian: bump Cabal submodule, install extra dynamic flavours of RTS

Previously, Hadrian was building all the appropriate dynamic ways for
libHSrts
but they were not picked up and installed in the package database when
we register the rts library. Since we use Cabal for registering
packages and
the .cabal files of packages as sources of truth for configuring and
installing,
we ended up patching Cabal to add a new field,
'extra-dynamic-library-flavours',
to specify those extra flavours to install in .cabal files:

    https://github.com/haskell/cabal/pull/5606

We now make use of this in rts.cabal.in to expose dynamic flavours
behind a
Cabal flag, which Hadrian will use whenever we are building a GHC
flavour that
requires dynamic libraries.

This is all part of a larger plan to build a dynamic stage 2 GHC by
default,
like with make, which in turn will fix a lot of test failures. See

Test Plan:
hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf
_build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so

Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar

Reviewed By: snowleopard, DavidEichmann

Subscribers: rwbarton, carter

GHC Trac Issues: #15837

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

Test Trac #15943

This test seems to work in HEAD

Comments only

Add Note [Dead case binders in -O0]

After reverting Phab:D5358, Simon (Peyton Jones) asked for a Note
summarising why we want to keep the dead case binder check in `cgCase`.

Summary from mail conversation:

* Phab:D5324 means that we no longer /recompute/ dead-ness of case-binders in
  STG-land

* But TidyPgm preserves dead-ness info (see CoreTidy.tidyIdBndr)

* And so we can take advantage of it to avoid a redundant load. This load
  would be eliminated by CmmSink, but that only happens with -O

Hadrian: improve bindist rule

As outlined in #15925, hadrian bindists had not made a clear choice with
respect to relocatable GHCs and wrapper scripts. This commit implements
the policy described in the ticket. That is:

- the bindists ship {bin, lib} as they are, modulo the addition of
  haddock from stage2/bin
- we now _always_ generate wrapper scripts for all the programs that
  are in the bindist's bin/ directory

The idea being that anyone on Linux/Windows/OS X can just unpack
the binary distribution anywhere and start using bin/ghc, while the
installation process systematicaly generates wrapper scripts.

Test Plan: hadrian/build.sh binary-dist ; cd
_build/bindist/ghc-X.Y.Z-arch/; configure --prefix=/tmp/foo && make
install

Reviewers: snowleopard, bgamari, angerman

Reviewed By: snowleopard, bgamari, angerman

Subscribers: rwbarton, carter

GHC Trac Issues: #15925

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

Fix #15941 by only special-casing visible infix applications

Summary:
The iface pretty-printer had a special case for an
application of an infix type constructor to two arguments. But this
didn't take the visibilities of the arguments into account, which
could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when
`-fprint-explicit-kinds` was enabled (#15941). The fix is relatively
straightforward: simply plumb through the visibilities of each
argument, and only trigger the special case for infix applications
if both arguments are visible (i.e., required).

Test Plan: make test TEST=T15941

Reviewers: goldfire, bgamari, monoidal

Reviewed By: goldfire, monoidal

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15941

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

Use autoconf to generate version numbers for libiserv and friends

Summary:
Currently, the version numbers for `libiserv`, `iserv`, and
`iserv-proxy` are hard-coded directly into their `.cabal` files.
These are easy to forget to update, and in fact, this has already
happened once (see #15866). Let's use `autoconf` to do this for us
so that it is not forgotten in the future.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, erikd, carter

GHC Trac Issues: #15866

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

Print explicit foralls in type family eqns when appropriate

Summary:
When `-fprint-explicit-foralls` is enabled, type family
equations are either printed without an explict `forall` entirely,
or with a bizarre square bracket syntax (in the case of closed type
families). I find neither satisfying, so in this patch, I introduce
support for printing explicit `forall`s in open type-family, closed
type-family, and data-family equations when appropriate. (By "when
appropriate", I refer to the conditions laid out in
`Note [When to print foralls]` in `IfaceType`.)

One tricky point in the implementation is that I had to pick a
visibility for each type variable in a `CoAxiom`/`FamInst` in order
to be able to pass it to `pprUserIfaceForAll` //et al.// Because
the type variables in a type family instance equation can't be
instantiated by the programmer anyway, the choice only really matters
for pretty-printing purposes, so I simply went with good ol'
trustworthy `Specified`. (This design choice is documented in
`Note [Printing foralls in type family instances]` in `IfaceType`.)

Test Plan: make test TEST=T15827

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15827

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

Fix build on darwin

CPP error introduced with b2950e0

Revert "Remove redundant check in cgCase"

This reverts commit d13b7d60650cb84af11ee15b3f51c3511548cfdb.

(See discussion in D5358)