GitLab

This clarifies that kind variables are inputs to type families
and can be used to distinguish instances.

This makes two changes to the documentation:

* Adds a comment in the release notes about the ability to
  quote primitive chars and strings in TH (see D1054)
* Removes an outdated comment in the users' guide about TH not
  being able to handle `PartialTypeSignatures` (which was fixed in
  D1048)

Reviewers: goldfire, austin, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

Handle anonymous wild cards in type or data family instance
declarations like
unnamed type variables. For instance (pun intented):

    type family F (a :: *) (b :: *) :: *
    type instance F Int _ = Int

Is now the same as:

    type family F (a :: *) (b :: *) :: *
    type instance F Int x = Int

Note that unlike wild cards in partial type signatures, no errors (or
warnings
with -XPartialTypeSignatures) are generated for these wild cards, as
there is
nothing interesting to report to the user, i.e. the inferred kind.

Only anonymous wild cards are supported here, named and
extra-constraints wild
card are not.

Test Plan: pass new tests

Reviewers: goldfire, austin, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: goldfire, thomie

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

GHC Trac Issues: #3699, #10586

Specify that the type variables for a class/instance decl scope
over the body even without a 'forall'.

Provoked by Trac #10722.

This implements the `StrictData` language extension, which lets the
programmer default to strict data fields in datatype declarations on a
per-module basis.

Specification and motivation can be found at
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

This includes a tricky parser change due to conflicts regarding `~` in
the type level syntax: all ~'s are parsed as strictness annotations (see
`strict_mark` in Parser.y) and then turned into equality constraints at
the appropriate places using `RdrHsSyn.splitTilde`.

Updates haddock submodule.

Test Plan: Validate through Harbormaster.

Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari

Reviewed By: simonpj, tibbe, bgamari

Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering

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

GHC Trac Issues: #8347

- Declaration splices: partial type signatures are fully supported in TH
  declaration splices.

  For example, the wild cards in the example below will unify with `Eq
a`
  and `a -> a -> Bool`, as expected:

```
[d| foo :: _ => _
    foo x y = x == y |]
```

- Expression splices: anonymous and named wild cards are supported in
  expression signatures, but extra-constraints wild cards aren't. Just
  as is the case for regular expression signatures.

```
[e | Just True :: _a _ |]
```

- Typed expression splices: the same wildcards as in (untyped)
  expression splices are supported.

- Pattern splices: TH doesn't support type signatures in pattern
  splices, consequently, partial type signatures aren't supported
  either.

- Type splices: partial type signatures are only partially supported in
  type splices, specifically: only anonymous wild cards are allowed.

  So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
  `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
  the named wild card is treated as a type variable).

  Normally, named wild cards are collected before renaming a (partial)
  type signature. However, TH type splices are run during renaming, i.e.
  after the initial traversal, leading to out of scope errors for named
  wild cards. We can't just extend the initial traversal to collect the
  named wild cards in TH type splices, as we'd need to expand them,
  which is supposed to happen only once, during renaming.

  Similarly, the extra-constraints wild card is handled right before
  renaming too, and is therefore also not supported in a TH type splice.
  Another reason not to support extra-constraints wild cards in TH type
  splices is that a single signature can contain many TH type splices,
  whereas it mustn't contain more than one extra-constraints wild card.
  Enforcing would this be hard the way things are currently organised.

  Anonymous wild cards pose no problem, because they start without names
  and are given names during renaming. These names are collected right
  after renaming. The names generated for anonymous wild cards in TH
  type splices will thus be collected as well.

  With a more invasive refactoring of the renaming, partial type
  signatures could be fully supported in TH type splices. As only
  anonymous wild cards have been requested so far, these small changes
  satisfying this request will do for now. Also don't forget that a TH
  declaration splices support all kinds of wild cards.

- Extra-constraints wild cards were silently ignored in expression and
  pattern signatures, appropriate error messages are now generated.

Test Plan: run new tests

Reviewers: austin, goldfire, adamgundry, bgamari

Reviewed By: goldfire, adamgundry, bgamari

Subscribers: thomie

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

GHC Trac Issues: #10094, #10548

DsMeta does not attempt to handle quasiquoted Char# or Addr# values,
which causes expressions like `$([| 'a'# |])` or `$([| "abc"# |])` to
fail
with an `Exotic literal not (yet) handled by Template Haskell` error.

To fix this, the API of `template-haskell` had to be changed so that
`Lit`
now has an extra constructor `CharPrimL` (a `StringPrimL` constructor
already
existed, but it wasn't used). In addition, `DsMeta` has to manipulate
`CoreExpr`s directly that involve `Word8`s. In order to do this,
`Word8` had
to be added as a wired-in type to `TysWiredIn`.

Actually converting from `HsCharPrim` and `HsStringPrim` to `CharPrimL`
and
`StringPrimL`, respectively, is pretty straightforward after that, since
both `HsCharPrim` and `CharPrimL` use `Char` internally, and
`HsStringPrim`
uses a `ByteString` internally, which can easily be converted to
`[Word8]`,
which is what `StringPrimL` uses.

Reviewers: goldfire, austin, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #10620

Reviewers: dolio, shachaf, ekmett, austin, #core_libraries_committee,
simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10447

Relates to Trac #10595

Depends on D864.

Previous behaviour was ErrorCall, which might mask issues in tests 
using -fdefer-type-errors
Signed-off-by: David Kraeutmann <kane@kane.cx>

Test Plan: Test whether the error thrown is indeed TypeError and not 
ErrorCall.

Reviewers: hvr, nomeata, austin

Reviewed By: nomeata, austin

Subscribers: nomeata, simonpj, thomie

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

GHC Trac Issues: #10284

Adds a flag -fwarn-deferred-type-errors similar to -fwarn-typed-holes.
Changes the boolean flag of -fdefer-type-errors to a 3-state flag 
similar to the one used by -fdefer-typed-holes/-fwarn-typed-holes.

Test Plan: Since only the absence of deferred type error warnings when 
-fno-warn-deferred-type-errors is passed has to be tested, I duplicated 
a test case checking -fdefer-type-errors and adjusted it accordingly.

Reviewers: nomeata, simonpj, austin, thomie, bgamari, hvr

Reviewed By: nomeata, simonpj, austin, thomie, bgamari, hvr

Subscribers: bgamari, simonpj, nomeata, thomie

Projects: #ghc

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

GHC Trac Issues: #10283

This patch implements the idea in Trac #10569.

* An out-of-scope variable is treated as a typed expression
  hole.

* That is, we don't report it in the type checker, not the
  renamer, and we when we do report it, we give its type.

* Moreover, we can defer the error to runtime with
  -fdefer-typed-holes

In implementation terms:

* The renamer turns an unbound variable into a HsUnboundVar

* The type checker emits a Hole constraint for a
  HsUnboundVar, and turns it back into a HsVar

It was a bit painful to implement because a whole raft of
error messages change slightly.  But there was absolutely
nothing hard in principle.

Holes are reported with a bunch of possibly-useful context,
notably the "relevant bindings".  I found that this was
distracting clutter in the very common case of a mis-typed
variable that is only accidentally not in scope, so I've
arranged to print the context information only for true holes,
that is ones starting with an underscore.

Unbound data constructors use in patterns, like
  f (D x) = x
are still reportd by the renamer, and abort compilation
before type checking.

Summary:
Today when reading through the users manual I noticed a few spelling issues.
This prompted me to run the document through ispell which turned up even more
issues. I've tried to be conservative here; most of the corrections are
misspellings and typos but in a few cases I've moved from American to British
orthography.

Test Plan: Read.

Reviewers: austin

Reviewed By: austin

Subscribers: bgamari, thomie

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

[skip ci]

The alternatives table gave the wrong glyphs for LEFTWARDS resp.
RIGHTWARDS ARROW-TAIL notation. The listed codepoint was correct,
but the entities corresponded to characters different from those
codepoints.

This also adds the glyphs for LEFTWARDS resp. RIGHTWARDS
DOUBLE ARROW-TAIL, which were formerly missing, and the PROPORTION
glyph, which was formerly given as ASCII.

Summary:
This commit adds stage 1 support for Template Haskell
quoting, e.g. [| ... expr ... |], which is useful
for authors of quasiquoter libraries that do not actually
need splices.  The TemplateHaskell extension now does not
unconditionally fail; it only fails if the renamer encounters
a splice that it can't run.

In order to make sure the referenced data structures
are consistent, template-haskell is now a boot library.
There are some minor BC changes to template-haskell to make it boot
on GHC 7.8.

Note for reviewer: big diff changes are simply code
being moved out of an ifdef; there was no other substantive
change to that code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10382

Revert "Quick fix: drop base bound on template-haskell."

This reverts commit 3c70ae03.

Revert "Always do polymorphic typed quote check, c.f. #10384"

This reverts commit 9a43b2c1.

Revert "RnSplice's staging test should be applied for quotes in stage1."

This reverts commit eb0ed403.

Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler."

This reverts commit 21c72e7d.

Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382."

This reverts commit 28257cae.

Summary:
This commit adds stage 1 support for Template Haskell
quoting, e.g. [| ... expr ... |], which is useful
for authors of quasiquoter libraries that do not actually
need splices.  The TemplateHaskell extension now does not
unconditionally fail; it only fails if the renamer encounters
a splice that it can't run.

In order to make sure the referenced data structures
are consistent, template-haskell is now a boot library.

In the following patches, there are:

    - A few extra safety checks which should be enabled
      in stage1
    - Separation of the th/ testsuite into quotes/ which
      can be run on stage1

Note for reviewer: big diff changes are simply code
being moved out of an ifdef; there was no other substantive
change to that code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10382

Fixes #9840 and #10306, and includes an alternative resolution to #8028.
This permits empty closed type families, and documents them in the user
guide. It updates the Haddock submodule to support the API change.

Test Plan: Added `indexed-types/should_compile/T9840` and updated
`indexed-types/should_fail/ClosedFam4` and `th/T8028`.

Reviewers: austin, simonpj, goldfire

Reviewed By: goldfire

Subscribers: bgamari, jstolarek, thomie, goldfire

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

GHC Trac Issues: #9840, #10306

In response to suggestions on Trac #10281

Don't suggest -XImpredicativeTypes; and document its flakiness
Fixes Trac #10325

This implements (roughly) the plan put forward in comment:14:ticket:7788,
fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079.
There are some regressions w.r.t. GHC 7.8, but only with pathological type
families (like F a = F a). This also (hopefully -- don't have a test case)
fixes #10158. Unsolved problems include #10184 and #10185, which are both
known deficiencies of the approach used here.

As part of this change, the plumbing around detecting infinite loops has
changed. Instead of -fcontext-stack and -ftype-function-depth, we now have
one combined -freduction-depth parameter. Setting it to 0 disbales the
check, which is now the recommended way to get (terminating) code to
typecheck in releases. (The number of reduction steps may well change between
minor GHC releases!)

This commit also introduces a new IntWithInf type in BasicTypes
that represents an integer+infinity. This type is used in a few
places throughout the code.

Tests in
  indexed-types/should_fail/T7788
  indexed-types/should_fail/T8550
  indexed-types/should_fail/T9554
  indexed-types/should_compile/T10079
  indexed-types/should_compile/T10139
  typecheck/should_compile/T10184  (expected broken)
  typecheck/should_compile/T10185  (expected broken)

This commit also changes performance testsuite numbers, for the better.

Summary:
This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
it solves them on the spot.

The current implementation creates `TyCon` representations on the spot.

Pro: No overhead at all in code that does not use `Typeable`
Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.

We have discussed an implementation where representations of `TyCons` are
computed once, in the module, where a datatype is declared.  This would
lead to more code being generated:  for a promotable datatype we need to
generate `2 + number_of_data_cons` type-constructro representations,
and we have to do that for all programs, even ones that do not intend to
use typeable.

I added code to emit warning whenevar `deriving Typeable` is encountered---
the idea being that this is not needed anymore, and shold be fixed.

Also, we allow `instance Typeable T` in .hs-boot files, but they result
in a warning, and are ignored.  This last one was to avoid breaking exisitng
code, and should become an error, eventually.

Test Plan:
1. GHC can compile itself.
2. I compiled a number of large libraries, including `lens`.
    - I had to make some small changes:
      `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
    - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance

3. I also run some code that uses `syb` to traverse a largish datastrucutre.
I didn't notice any signifiant performance difference between the 7.8.3 version,
and this implementation.

Reviewers: simonpj, simonmar, austin, hvr

Reviewed By: austin, hvr

Subscribers: thomie

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

GHC Trac Issues: #9858

This just documents the conclusions of Trac #10132

See Trac #7854.  Specifically:

* Major clean up and simplification of check_op in checkValidClass;
  specifically
     - use checkValidType on the entire method-selector type to detect
       ambiguity
     - put a specific test for -XConstrainedClassMethods

* Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses
  (a bit ad-hoc but see #7854), and document in the user manual.

* Do the checkAmbiguity test just once in TcValidity.checkValidType,
  rather than repeatedly at every level. See Note [When to call checkAmbiguity]

* Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous.
  (It's a rather magic function.)

* Improve location info for check_op in checkValidClass

* Update quite a few tests, which had genuinely-ambiguous class
  method signatures.  Some I fixed by making them unambiguous; some
  by adding -XAllowAmbiguousTypes

* The original fix was to improve the documentation, in
  line with the suggestions on Trac #10122

* But in doing so I realised that the kind generalisation in
  TcRnDriver.tcRnType was completely wrong.  So I fixed that
  and updated Note [Kind-generalise in tcRnType] to explain.

Summary: Added packageName to GHC.Generics.Datatype class definition

Reviewers: hvr, dreixel, austin

Reviewed By: dreixel, austin

Subscribers: thomie

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

GHC Trac Issues: #10030

Summary:
IPs with this type will always be solved for the current source
location. If another IP of the same type is in scope, the two locations will be
appended, creating a call-stack. The Location type is kept abstract so users
cannot create them, but a Location can be turned into a list of SrcLocs, which
correspond to individual locations in a program. Each SrcLoc contains a
package/module/file name and start/end lines and columns.

The only thing missing from the SrcLoc in my opinion is the name of the
top-level definition it inhabits. I suspect that would also be useful, but it's
not clear to me how to extract the current top-level binder from within the
constraint solver. (Surely I'm just missing something here?)

I made the (perhaps controversial) decision to have GHC completely ignore
the names of Location IPs, meaning that in the following code:

    bar :: (?myloc :: Location) => String
    bar = foo

    foo :: (?loc :: Location) => String
    foo = show ?loc

if I call `bar`, the resulting call-stack will include locations for

1. the use of `?loc` inside `foo`,
2. `foo`s call-site inside `bar`, and
3. `bar`s call-site, wherever that may be.

This makes Location IPs very special indeed, and I'm happy to change it if the
dissonance is too great.

I've also left out any changes to base to make use of Location IPs, since there
were some concerns about a snowball effect. I think it would be reasonable to
mark this as an experimental feature for now (it is!), and defer using it in
base until we have more experience with it. It is, after all, quite easy to
define your own version of `error`, `undefined`, etc. that use Location IPs.

Test Plan: validate, new test-case is testsuite/tests/typecheck/should_run/IPLocation.hs

Reviewers: austin, hvr, simonpj

Reviewed By: simonpj

Subscribers: simonmar, rodlogic, carter, thomie

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

GHC Trac Issues: #9049

Summary:
see Trac #8624

similar functionality is now available
with -ddump-to-file -ddump-splices

However, users are already accustomed to -ddump-splices
having a particular format, and this format is not completely valid code
The goal of -th-file is to dump valid Haskell code

Additionally, the convention of -ddump-to-file is to name the file after
the flag, so the file is .dump-splices
Given that the goal of the new flag is to generate valid Haskell,
The extension should be .hs

Additionally, -ddump-to-file effects all other dump flags

Test Plan:
look at the output of using the -th-file flag
and compare it to the output of using -ddump-to-file and -ddump-splices
I want to add test cases, but just need some pointers on getting started there

Reviewers: thomie, goldfire, simonpj, austin

Reviewed By: simonpj, austin

Subscribers: thomie, carter

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

GHC Trac Issues: #8624

I ended up introducing a new sub-section on instance termination.