GitLab

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

Fixing this required reworking candidateQTyVarsOfType, the function
that extracts free variables as candidates for quantification.
One consequence is that we now must be more careful when quantifying:
any skolems around must be quantified manually, and quantifyTyVars
will now only quantify over metavariables. This makes good sense,
as skolems are generally user-written and are listed in the AST.

As a bonus, we now have more control over the ordering of such
skolems.

Along the way, this commit fixes #15711 and refines the fix
to #14552 (by accepted a program that was previously rejected,
as we can now accept that program by zapping variables to Any).

This commit also does a fair amount of rejiggering kind inference
of datatypes. Notably, we now can skip the generalization step
in kcTyClGroup for types with CUSKs, because we get the
kind right the first time. This commit also thus fixes #15743 and
 #15592, which both concern datatype kind generalisation.
(#15591 is also very relevant.) For this aspect of the commit, see
Note [Required, Specified, and Inferred in types] in TcTyClsDecls.

Test cases: dependent/should_fail/T14880{,-2},
            dependent/should_fail/T15743[cd]
            dependent/should_compile/T15743{,e}
            ghci/scripts/T15743b
            polykinds/T15592
            dependent/should_fail/T15591[bc]
            ghci/scripts/T15591

Summary:
Commit 512eeb9b
(`More explicit foralls (GHC Proposal 0007)`) introduced breaking
changes to the Template Haskell AST. As a consequence of this, there
are libraries in the wild that now fail to build on GHC HEAD (for
instance, `th-abstraction`).

This properly bumps the `template-haskell` library's version number
to `2.15.0.0` so that these libraries can guard against these changes
using `MIN_VERSION_template_haskell`.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15818

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

Summary:
Reimplement global FastString table using a concurrent hashatable with
fixed size segments and dynamically growing buckets instead of fixed size
buckets.

This addresses the problem that `mkFastString` was not linear when the
total number of entries was large.

Test Plan:
./validate

```
inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null
GHCi, version 8.7.20181005: http://www.haskell.org/ghc/  :? for help
Prelude> Leaving GHCi.
FastString stats:
    segments:          256
    buckets:           16384
    entries:           7117
    largest segment:   64
    smallest segment:  64
    longest bucket:    5
    has z-encoding:    0%
```

Also comapre the two implementation using

{P187}

The new implementation is on a par with the old version with different
conbination of parameters and perform better when the number of
FastString's are large.

{P188}

Reviewers: simonmar, bgamari, niteria

Reviewed By: simonmar, bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #14854

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

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Summary:
We saw following errors:

```
$ cabal install --disable-library-vanilla --disable-shared --enable-library-profiling
hashable-1.2.7.0: cannot find any of
["libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ.a",
 "libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ.p_a",
 "libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ-ghc8.4.3.so",
 "libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ-ghc8.4.3.dylib",
 "HShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ-ghc8.4.3.dll"]
```

This is because ghc-pkg is looking for
`libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ.p_a` instead of
`libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ_p.a`.

Test Plan: ./validate

Reviewers: simonmar, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

Summary:
Previously the TcPlugin and CorePlugin type synonyms were not exporting,
resulting in much confusion.

Reviewers: mpickering

Reviewed By: mpickering

Subscribers: rwbarton, carter

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

Summary:
This failure was originally tracked in #15066 but it seems the problem
has somehow resolved itself.

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, carter

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

Summary:
on windows, plugins are loaded via .a files,
but those paths were not being searched when loading plugins

Test Plan: ./validate

Reviewers: Phyx, bgamari

Reviewed By: Phyx

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #15700

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

Summary:
This patch fixes #15805, where we found that
`TcType.anyRewritableTyVar` has one wrong case.

Besides the fix, it also:
- removed some unnecessary `ASSERT2(tcIsTcTyVar...)` in `TcType`, as now we have
     `tcIsTcTyVar = isTyVar`.
- fixed some comments

Test Plan: ./validate

Reviewers: goldfire, simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #15805

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

Summary:
Although these functions were marked as CONSTANT_FOLDED, they did
not have a corresponding builtinRule in PrelRules. The idea was
probably to add them eventually, but this hasn't manifested so
far.

The plan is to eventually add builtin rules for these functions
over Natural, so as a reminder we simply comment out the
CONSTANT_FOLDED  annotation instead of removing it completely.

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Summary:
Ticket #15271 reports a case where 1e1000000000 is incorrectly
converted to 0.0. After some investigation, I discovered the number is
converted to rational correctly, but converting the ratio into a double
introduced an error.

Tracking down to how the conversion is done, I found the rts float
implementation uses `ldexp`, whose signature is
`double ldexp (double x, int exp);`
The callsite passes an `I_` to the second argument, which is
platform-dependent. On machines where `I_` is 64 bits and `int` is 32 bits, we
observe integer overflow behaviour.

Here is a mapping from rational to exponent with observations
1e646457008  -> 2147483645 (result = infinity, positive in int32)
1e646457009  -> 2147483648 (result = 0.0, overflow to negative in int32)
1e1000000000 -> 3321928042 (result = infinity, overflow to positive in int32)
1e1555550000 -> 5167425196 (result = 0.0, overflow to negative in int32)

We fix this issue by comparing STG_INT_MIN/MAX and INT_MIN/MAX and bound the
value appropriately.

Test Plan: New test cases

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15271

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

Summary:
This patch fixes #15806, where we found that the `:k` command in GHCi
misses a validity checking for the type.

Missing validity checking causes `:k` to accept types that are not validated.
For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while
impredictivity of type instantiation shouldn't be allowed.

Test Plan: ./validate

Reviewers: simonpj, goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15806

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

Summary:
Fixes #14784. Note that C++11 is quite conservative; we could likely accept
C++03 as well.

Test Plan:
```
$ cat >hi.c <<EOF
#include <Rts.h>
EOF
$ g++ -std=c++11 hi.c
```

Reviewers: simonmar, hvr

Subscribers: rwbarton, carter

GHC Trac Issues: #14784

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

Summary:
Encountered assembly error due to undefined label `.LcaDcU_info_end` for
following code generated by `pprFrameProc`:

```
.Lsat_sa8fp{v}_info_fde_end:
  .long .Lblock{v caDcU}_info_fde_end-.Lblock{v caDcU}_info_fde
.Lblock{v caDcU}_info_fde:
  .long _nbHlD-.Lsection_frame
  .quad block{v caDcU}_info-1
  .quad .Lblock{v caDcU}_info_end-block{v caDcU}_info+1
  .byte 1
```

This diff fixed the error.

Test Plan:
  ./validate

Also the case where we used to have assembly error is now fixed.
Unfortunately, I have limited insight here and cannot get a small enough repro
or test case for this.

Ben says:

> I think I see: Previously we only produced end symbols for the info
> tables of top-level procedures. However, blocks within a procedure may
> also have info tables, we will dutifully generate debug information for
> and consequently we get undefined symbols.

Reviewers: simonmar, scpmw, last_g, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

We now calculate the SSE register padding needed to fix the calling
convention in LLVM in a robust way: grouping them by whether
registers in that class overlap (with the same class overlapping
itself).

My prior patch assumed that no matter the platform, physical
register Fx aliases with Dx, etc, for our calling convention.

This is unfortunately not the case for any platform except x86-64.

Test Plan:
Only know how to test on x86-64, but it should be tested on ARM with:

`make test WAYS=llvm && make test WAYS=optllvm`

Reviewers: bgamari, angerman

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15780, #14251, #15747

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

Allow the user to explicitly bind type/kind variables in type and data
family instances (including associated instances), closed type family
equations, and RULES pragmas. Follows the specification of GHC
Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.

This modifies the Template Haskell AST -- old code may break!

Other Changes:
- convert HsRule to a record
- make rnHsSigWcType more general
- add repMaybe to DsMeta

Includes submodule update for Haddock.

Test Plan: validate

Reviewers: goldfire, bgamari, alanz

Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
             thomie, mpickering, carter

GHC Trac Issues: #2600, #14268

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

Consider the type
  forall k. b -> k
where
  b :: k -> Type

Here the 'k' in b's kind must be a different 'k' to the forall k,
because 'b' is free in the expression.  So we must return 'k'
among the free vars returned from tyCoVarsOfType applied that
type.  But we weren't.

This is an outright bug, although we don't have a program that
fails because of it.

It's easy to fix, too: see TyCoRep
  Note [Closing over free variable kinds]

This fix has been in the pipeline for ages because it fell into
the Trac #14880 swamp.  But this patch nails it.

Fixing the way that we close-over-kinds when taking the
free vars of a type revealed that the way we generalise
type constructors was a bit wrong.

This fixes it.  See TcTyClDecls
Note [Generalisation for type constructors]

As Trac #15765 says, Once upon a time, the extract functions
at the bottom of RnTypes were pure. Then, along came -XTypeInType,
which needed to do a check in these functions for users mixing
type variables with kind variables.

Now, however, with -XTypeInType gone again, we no longer
do this check. Thus, there is no reason to keep these
functions monadic.

Summary:
Update details for `ForAllTy` and `ForAllCo` in core-spec, as they
can now quantify over coercion variables.

Test Plan: Please read core-spec.pdf

Reviewers: goldfire, simonpj, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, carter

GHC Trac Issues: #15497, #15589

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

An attempt to help with Trac #15800

This patch fixes Trac #15778 by removing a zonkTcTyVarToTyVar
from tcHsSigType.

Nww that a pattern-bound type variable can refer to a type, it's
obvoiusly wrong to expect it to be a TyVar!  Moreover, that zonk
is entirely unnecessary.

I added a new Note [Type variables in the type environment]
in TcRnTypes

This just improves docmentation for the fix to Trac #15300

Change some URLs from hackage.haskell.org/trac to ghc.haskell.org/trac

Test Plan: manually verify links work

Reviewers: bgamari, simonmar, mpickering

Reviewed By: bgamari, mpickering

Subscribers: mpickering, rwbarton, carter

GHC Trac Issues: #15733

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

In TcSimplify.neededEvVars, in add_implic_seeds we were
deleting the 'givens'; but they are already deleted, so
this is a no-op.  This patch just remove the redundant
delete.

This is a debug-only change

We suppress some Given errors; see Note [Given errors]
in TcErrors.  But we must be careful not to suppress
Wanted errors because of the presence of these Given
errors -- else we might allow compilation to bogusly
proceed

The rubber hits the road in TcRnTypes.insolubleCt,
where we don't want to treat Givens as insoluble,
nor (and this is the new bit) Deriveds that arise
from Givens.  See Note [Given insolubles] in TcRnTypes.

This fixes #15767.

A debug-print was trying to print the coercion returned
by the flattener.  But that coercion can be undefined
in the case of Derived constraints.  Because we might
rewrite it with [D] a ~ ty, and there is no evidence
for that.

Solution: don't attempt to print the coercion.

Trac #15694 showed that we were forgetting to solve
the equalities of a pattern signature until too late.

Result: WARNINGs and a panic:
  "Type-correct unfilled coercion hole"

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