GitLab

Trac #15648 showed that GHC was a bit confused about the
difference between the types for

* Predicates
* Coercions
* Evidence (in the typechecker constraint solver)

This patch cleans it up. See especially Type.hs
Note [Types for coercions, predicates, and evidence]

Particular changes

* Coercion types (a ~# b) and (a ~#R b) are not predicate types
  (so isPredTy reports False for them) and are not implicitly
  instantiated by the type checker.  This is a real change, but
  it consistently reflects that fact that (~#) and (~R#) really
  are different from predicates.

* isCoercionType is renamed to isCoVarType

* During type inference, simplifyInfer, we do /not/ want to infer
  a constraint (a ~# b), because that is no longer a predicate type.
  So we 'lift' it to (a ~ b). See TcType
  Note [Lift equality constaints when quantifying]

* During type inference for pattern synonyms, we need to 'lift'
  provided constraints of type (a ~# b) to (a ~ b).  See
  Note [Equality evidence in pattern synonyms] in PatSyn

* But what about (forall a. Eq a => a ~# b)? Is that a
  predicate type?  No -- it does not have kind Constraint.
  Is it an evidence type?  Perhaps, but awkwardly so.

  In the end I decided NOT to make it an evidence type,
  and to ensure the the type inference engine never
  meets it.  This made me /simplify/ the code in
  TcCanonical.makeSuperClasses; see TcCanonical
  Note [Equality superclasses in quantified constraints]

  Instead I moved the special treatment for primitive
  equality to TcInteract.doTopReactOther.  See TcInteract
  Note [Looking up primitive equalities in quantified constraints]

  Also see Note [Evidence for quantified constraints] in Type.

  All this means I can have
     isEvVarType ty = isCoVarType ty || isPredTy ty
  which is nice.

All in all, rather a lot of work for a small refactoring,
but I think it's a real improvement.

This patch makes a number of improvements to the output
generated by -ddump-types

* Prints data constructor separately
* Omits empty chunks of output

I was driven initially by the unhelpful existing output for
data constructors, but ended up doing some refactoring.

Lots of error message wibbles, but nothing significant.
Certainly no change in user behaviour.

(NB: It is just possible that I have failed to cleanly
     separate this patch from the next one, about
     isPredTy and friends.)

Summary:
The `reifyType` function in `TcSplice` is carefully designed
to avoid reifying visible arguments to `TyConApp`s. However, the same
care was not given towards the `AppTy` case, which lead to #15792.

This patch changes to the `AppTy` case of `reifyType` so that it
consults the kind of the function type to determine which of the
argument types are invisible (and therefore should be dropped) during
reification. This required crafting a variant of `tyConArgFlags`,
which I dubbed `appTyArgFlags`, that accept an arbitrary function
`Type` instead of a `TyCon`.

Test Plan: make test TEST=T15792

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15792

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

Summary:
When renaming untyped TH quotes, some care is taken to
ensure that uses of top-level names in quotes do not have their
bindings discarded during desugaring. The same care was not applied
to typed TH quotes, so this patch brings the two into sync.

Test Plan: make test TEST=T15783

Reviewers: bgamari, mpickering

Reviewed By: mpickering

Subscribers: mpickering, rwbarton, carter

GHC Trac Issues: #15783

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

Summary:
This is a follow-up to D5173, which permitted
unparenthesized kind signatures in certain places. One place that
appeared to be overlooked was the right-hand sides of type synonyms,
which this patch addresses by introducing a `ktypedoc` parser
production (which is to `ctypdoc` as `ktype` is to `ctype`) and
using it in the right place.

Test Plan: make test TEST="KindSigs T15781"

Reviewers: harpocrates, bgamari

Reviewed By: harpocrates

Subscribers: rwbarton, mpickering, carter

GHC Trac Issues: #15781

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

Summary:
In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten
edge case in ALR, since `maybe_layout` (which handles the non-ALR layout)
already deals with the 'ITlcase' token properly.

Test Plan: make TEST=T10453 && make TEST=T13087

Reviewers: bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #10453, #13087

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

git-subtree-dir: hadrian
git-subtree-mainline: 575b35f4
git-subtree-split: 45f3bff7

See #15349.

Comments only: [skip ci]

Summary:
This works around #15758 by bumping hsc2hs.

The new version includes support for response files
independent of the boot compiler.

Test Plan: ci, building formerly broken packages

Reviewers: bgamari, RyanGlScott, ckoparkar

Reviewed By: ckoparkar

Subscribers: rwbarton, carter

GHC Trac Issues: #15758

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

Summary:
For the sake of consistency of the dependent core, there is a restriction on
where a coercion variable can appear in ForAllCo: the coercion variable can
appear nowhere except in coherence coercions.

Currently this restriction is missing in Core. The goal of this patch is to add
the missing restriction.

After discussion, we decide: coercion variables can appear nowhere except in
`GRefl` and `Refl`. Relaxing the restriction to include `Refl` should not break
consistency, we premuse.

Test Plan: ./validate

Reviewers: goldfire, simonpj, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, carter

GHC Trac Issues: #15757

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

Summary:
It failed when running ./validate on master
T15729 is added by me in D5219 recently,
it failed when GHCi is dynamicly linked:

```
Stderr ( T15729 ):
/bin/ld.gold: error: bss.o: requires unsupported dynamic reloc 11;
recompile with -fPIC
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
```

Test Plan: Both tests pass now.

Reviewers: simonmar, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

This was just a pretty-printer infelicity. Fixed now.

Test case: printer/T15761

I've added a check in my release script to ensure that this doesn't happen in
the future.

Summary:
Original proposal by Andrew Martin:
https://mail.haskell.org/pipermail/libraries/2018-June/028852.html

Reviewers: andrewthad, hvr, bgamari, alpmestan, tdammers

Reviewed By: bgamari, alpmestan, tdammers

Subscribers: alpmestan, rwbarton, thomie, carter

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

Reviewers: hvr, bgamari, monoidal

Reviewed By: monoidal

Subscribers: rwbarton, carter

GHC Trac Issues: #15350

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

When inspecing a BLACKHOLE if the BLACKHOLE points to a TSO or a
BLOCKING_QUEUE we should return a suspension to the BLACKHOLE itself
(instead of returning a suspension to the indirectee). The reason is
because in the debugger when we want to evaluate this term we need to
enter the BLACKHOLE and not to the TSO or BLOCKING_QUEUE. See the
runtime panic caused by this in #8316.

Note that while with this patch we do the right thing to evaluate
thunks in GHCi, evaluating thunks that are owned by the evaluator thread
in a breakpoint will cause a deadlock as we don't release the breakMVar,
which is what blocks the evaluator thread from continuing with
evaluation. So the GHCi thread will enter the BLACKHOLE, but owner of
the BLACKHOLE is also blocked.

Reviewers: simonmar, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #8316

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

Allocate bss section within proper range of other sections:

* when `+RTS -xp` is passed, allocate it contiguously as we did for
  jump islands
* when we mmap the code to lower 2Gb, we should allocate bss section
  there too

This depends on {D5195}

Test Plan:
1. `./validate`

2.

with

```
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO
```

`TEST="T15729" make test` passed in both linux and macos.

3.

Also test in a use case where we used to encouter error like:

```
ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) =
b90282ba
```

and now, everything works fine.

Reviewers: simonmar, bgamari, angerman, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15729

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

Add a RTS option -xp to load PIC object anywhere in address space. We do
this by relaxing the requirement of <0x80000000 result of
`mmapForLinker` and implying USE_CONTIGUOUS_MMAP.

We also need to change calls to `ocInit` and `ocGetNames` to avoid
dangling pointers when the address of `oc->image` is changed by
`ocAllocateSymbolExtra`.

Test Plan:
```
$ uname -a
Linux localhost 4.18.8-arch1-1-ARCH #1 SMP PREEMPT Sat Sep 15 20:34:48
UTC 2018 x86_64 GNU/Linux
$ cat mk/build.mk
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO

GhcRTSWays += thr_debug
EXTRA_HC_OPTS += -debug
WAY_p_HC_OPTS += -fPIC -fexternal-dynamic-refs
$ inplace/bin/ghc-stage2 --interactive -prof +RTS -xp
GHCi, version 8.7.20180928: http://www.haskell.org/ghc/  :? for help
ghc-stage2: R_X86_64_32 relocation out of range:
ghczmprim_GHCziTypes_ZMZN_closure = 7f690bffab59
Recompile
/data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim
-0.5.3.o with -fPIC -fexternal-dynamic-refs.
ghc-stage2: unable to load package `ghc-prim-0.5.3'
$ strace -f -e open,mmap inplace/bin/ghc-stage2 --interactive -prof
-fexternal-interpreter  -opti+RTS -opti-xp
...
[pid 1355283]
open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas
e-4.12.0.0_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84842000
[pid 1355283]
open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas
e-4.12.0.0_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84676000
...
Prelude> System.Posix.Process.getProcessID
...
[pid 1355283]
open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni
x-2.7.2.2_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 45056, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d60000
[pid 1355283]
open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni
x-2.7.2.2_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 57344, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d52000
...
```

```
$ uname -a
Darwin watashis-iMac.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug
22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64
$ mv
/Users/watashi/gao/ghc/libraries/integer-gmp/dist-install/build/HSintege
r-gmp-1.0.2.0.o{,._DISABLE_GHC_ISSUE_15105}
$ inplace/bin/ghc-stage2 --interactive  +RTS -xp
GHCi, version 8.7.20181003: http://www.haskell.org/ghc/  :? for help
Prelude> System.Posix.Process.getProcessID
42791
Prelude> Data.Set.fromList [1 .. 10]
fromList [1,2,3,4,5,6,7,8,9,10]
Prelude>
Leaving GHCi.
$ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter
GHCi, version 8.7.20181003: http://www.haskell.org/ghc/  :? for help
Prelude> System.Posix.Process.getProcessID
42806
Prelude> Data.Set.fromList [1 .. 10]
fromList [1,2,3,4,5,6,7,8,9,10]
Prelude>
Leaving GHCi.
```

Also test with something that used to hit the 2Gb limit and it loads
and runs without problem.

Reviewers: simonmar, bgamari, angerman, Phyx, hvr, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

Enabling -Werror=compat in the testsuite allows us to easily see the
impact that a new warning has on code. It also means that in the period
between adding the warning and making the actual breaking change, all
new test cases that are being added to the testsuite will be
forwards-compatible. This is good because it will make the actual
breaking change contain less irrelevant testsuite updates.

Things that -Wcompat warns about are things that are going to break in
the future, so we can be proactive and keep our testsuite
forwards-compatible.

This patch consists of two main changes:

* Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration.
* Fix all broken test cases.

Test Plan: Validate

Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott

Reviewed By: goldfire, RyanGlScott

Subscribers: rwbarton, carter

GHC Trac Issues: #15278

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

We need to write the closure type as a HalfWord not
an Int. On big endian systems the closure type ends up being zero
(the upper word of the Int) making the closure an invalid object.

Test Plan: validate (preferably on a big endian system)

Reviewers: bgamari, hvr, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

We used to always generate direct access for cost centre labels.  We
fixed this by generating indirect data load for cost centre defined in
external module.

Test Plan:
The added test used to fail with error message
```
/bin/ld.gold: error: T15723B.o: requires dynamic R_X86_64_PC32 reloc
against 'T15723A_foo1_EXPR_cc' which may overflow at runtime; recompile
with -fPIC
```
and now passes.

Also check that `R_X86_64_PC32` is generated for CostCentre from the
same module and `R_X86_64_GOTPCREL` is generated for CostCentre from
external module:
```
$ objdump -rdS T15723B.o
0000000000000028 <T15723B_test_info>:
  28:   48 8d 45 f0             lea    -0x10(%rbp),%rax
  2c:   4c 39 f8                cmp    %r15,%rax
  2f:   72 70                   jb     a1 <T15723B_test_info+0x79>
  31:   48 83 ec 08             sub    $0x8,%rsp
  35:   48 8d 35 00 00 00 00    lea    0x0(%rip),%rsi        # 3c
<T15723B_test_info+0x14>
                        38: R_X86_64_PC32
T15723B_test1_EXPR_cc-0x4
  3c:   49 8b bd 60 03 00 00    mov    0x360(%r13),%rdi
  43:   31 c0                   xor    %eax,%eax
  45:   e8 00 00 00 00          callq  4a <T15723B_test_info+0x22>
                        46: R_X86_64_PLT32      pushCostCentre-0x4
  4a:   48 83 c4 08             add    $0x8,%rsp
  4e:   48 ff 40 30             incq   0x30(%rax)
  52:   49 89 85 60 03 00 00    mov    %rax,0x360(%r13)
  59:   48 83 ec 08             sub    $0x8,%rsp
  5d:   49 8b bd 60 03 00 00    mov    0x360(%r13),%rdi
  64:   48 8b 35 00 00 00 00    mov    0x0(%rip),%rsi        # 6b
<T15723B_test_info+0x43>
                        67: R_X86_64_GOTPCREL   T15723A_foo1_EXPR_cc-0x4
  6b:   31 c0                   xor    %eax,%eax
  6d:   e8 00 00 00 00          callq  72 <T15723B_test_info+0x4a>
                        6e: R_X86_64_PLT32      pushCostCentre-0x4
  72:   48 83 c4 08             add    $0x8,%rsp
  76:   48 ff 40 30             incq   0x30(%rax)
```

Reviewers: simonmar, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15723

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

With `QuantifiedConstraints`, `forall`s can appear in more
nested positions than they could before, but `Convert` and the TH
pretty-printer were failing to take this into account. On the
`Convert` side, this is fixed by using a `parenthesizeHsContext`
to parenthesize singleton quantified constraints that appear to the
left of a `=>`. (A similar fix is applied to the TH pretty-printer.)

Test Plan: make test TEST=T15738

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15738

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

Test Plan: This validates

Reviewers: simonpj, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

We weren't expanding type synonyms when determining the
injective type variables of a type, leading to certain non-injective
families being mistakenly labeled as injective (#12430). Easily fixed
with a tactical use of `coreView`.

Test Plan: make test TEST=T12430

Reviewers: bgamari, goldfire

Reviewed By: goldfire

Subscribers: goldfire, rwbarton, carter

GHC Trac Issues: #12430

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

Reviewers: bgamari, alanz

Reviewed By: bgamari

Subscribers: sgraf, mpickering, rwbarton, thomie, carter

GHC Trac Issues: #13600

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

This isn't as efficient as it could be since it needs to compute the
kind of the type. However, this is `show` so there shouldn't be any
particular expectation of speed.

Fixes #14341.

Test Plan: Validate

Reviewers: hvr

Subscribers: monoidal, rwbarton, carter

GHC Trac Issues: #14341

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

- Remove dph from validate; dph was removed
- The required-tag argument to boot was used only for dph, remove
- check_boot_packages() was not called at all, and didn't work.
  I fixed it based on previous Perl version.

Test Plan: Harbormaster

Reviewers: bgamari, thomie

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Unfortunately the implementation has confused the ability to make
dynamic libraries with dynamic way.
This constraint is only true for systems that require `-fPIC` for
shared libraries.

Since the implementation has this implicit assumption, mark the tests
as requiring dynway.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, carter

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

Summary:
The behavior previously enabled by this flag is as been the default
since 8.6.1.

Reviewers: simonmar

Subscribers: rwbarton, carter

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

PR: https://github.com/ghc/ghc/pull/203/

PR: https://github.com/ghc/ghc/pull/198/

Summary:
This is part 1 from #14880: factor out a worker for the tyCoVarsOf... family of
function, implementing them in terms of VarSet, but with accumulator-style
(like in `FV`) built in, and with the same kind of pre-insert lookup; this
has shown to perform better than either FV or plain VarSet in this particular
scenario.

Original notes from simonpj:

In TyCoRep we now have tyCoVarsOfType implemented

1) Using FV -- this is the baseline version in GHC today

2) Using VarSets via unionVarSet

3) Using VarSets in accumulator-style

In this patch (3) is enabled.

When compiling perf/compiler/T5631 we get

         Compiler allocs
   (1)   1,144M
   (2)   1,175M
   (3)   1,142M

The key new insight in (3) is this:

  ty_co_vars_of_type (TyVarTy v) is acc
    | v `elemVarSet` is  = acc
    | v `elemVarSet` acc = acc   <---- NB!
    | otherwise          = ty_co_vars_of_type (tyVarKind v) is (extendVarSet acc v)

Notice the second line! If the variable is already in the
accumulator, don't re-add it.  This makes big difference.
Without it, allocation is 1,169M or so.

One cause is that we only take the free vars of its kind once;
that problem will go away when we do the main part of #14088 and
close over kinds /afterwards/.  But still, another cause is perhaps
that every insert into a set overwrites the previous item, and so
allocates a new path to the item; it's not a no-op even if the
item is there already.

Why use (3) rather than (1)?  Becuase it just /has/ to
be better;

* FV carries around an InterestingVarFun, which does nothing
  useful here, but is tested at every variable

* FV carries around a [Var] for the deterministic version.

For this very hot operation (finding free vars) I think it
makes sense to have speical purpose code.

On the way I also simplified the (less used) coVarsOfType/Co family
to use FV, by making serious use of the InterestingVarFun!

Test Plan: validate, nofib

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #14880

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

Summary:
We were adding a `Sym` to one argument in the `InstCo`
case of `optCoercion` but not another, leading to the two arguments
to misaligned when combined via `Trans`. This fixes the issue with
a well targeted use of `wrapSym`.

Test Plan: make test TEST=T15725

Reviewers: goldfire, ningning, bgamari

Reviewed By: goldfire, ningning

Subscribers: rwbarton, carter

GHC Trac Issues: #15725

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