Allow PartialTypeSignatures in standalone deriving contexts
authorRyan Scott <ryan.gl.scott@gmail.com>
Fri, 23 Mar 2018 16:06:04 +0000 (12:06 -0400)
committerRyan Scott <ryan.gl.scott@gmail.com>
Fri, 23 Mar 2018 16:06:05 +0000 (12:06 -0400)
commitaffdea82bb70e5a912b679a169c6e9a230e4c93e
tree1200f0f3cb2735a45017be61808b709f24c4db49
parentd5577f44eaf3b9dfdfc77828038782bf818c176a
Allow PartialTypeSignatures in standalone deriving contexts

Summary:
At its core, this patch is a simple tweak that allows a user
to write:

```lang=haskell
deriving instance _ => Eq (Foo a)
```

Which is functionally equivalent to:

```lang=haskell
data Foo a = ...
  deriving Eq
```

But with the added flexibility that `StandaloneDeriving` gives you
(namely, the ability to use it anywhere, not just in the same module
that `Foo` was declared in). This fixes #13324, and should hopefully
address a use case brought up in #10607.

Currently, only the use of a single, extra-constraints wildcard is
permitted in a standalone deriving declaration. Any other wildcard
is rejected, so things like
`deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.

There are quite a few knock-on changes brought on by this change:

* The `HsSyn` type used to represent standalone-derived instances
  was previously `LHsSigType`, which isn't sufficient to hold
  wildcard types. This needed to be changed to `LHsSigWcType` as a
  result.

* Previously, `DerivContext` was a simple type synonym for
  `Maybe ThetaType`, under the assumption that you'd only ever be in
  the `Nothing` case if you were in a `deriving` clause. After this
  patch, that assumption no longer holds true, as you can also be
  in this situation with standalone deriving when an
  extra-constraints wildcard is used.

  As a result, I changed `DerivContext` to be a proper datatype that
  reflects the new wrinkle that this patch adds, and plumbed this
  through the relevant parts of `TcDeriv` and friends.

* Relatedly, the error-reporting machinery in `TcErrors` also assumed
  that if you have any unsolved constraints in a derived instance,
  then you should be able to fix it by switching over to standalone
  deriving. This was always sound advice before, but with this new
  feature, it's possible to have unsolved constraints even when
  you're standalone-deriving something!

  To rectify this, I tweaked some constructors of `CtOrigin` a bit
  to reflect this new subtlety.

This requires updating the Haddock submodule. See my fork at
https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7

Test Plan: ./validate

Reviewers: simonpj, goldfire, bgamari

Reviewed By: simonpj

Subscribers: goldfire, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #13324

Differential Revision: https://phabricator.haskell.org/D4383
21 files changed:
compiler/deSugar/DsMeta.hs
compiler/hsSyn/Convert.hs
compiler/hsSyn/HsDecls.hs
compiler/parser/Parser.y
compiler/rename/RnSource.hs
compiler/rename/RnTypes.hs
compiler/typecheck/TcDeriv.hs
compiler/typecheck/TcDerivInfer.hs
compiler/typecheck/TcDerivUtils.hs
compiler/typecheck/TcErrors.hs
compiler/typecheck/TcRnTypes.hs
docs/users_guide/8.6.1-notes.rst
docs/users_guide/glasgow_exts.rst
testsuite/tests/partial-sigs/should_compile/T13324_compile.hs [new file with mode: 0644]
testsuite/tests/partial-sigs/should_compile/all.T
testsuite/tests/partial-sigs/should_fail/T13324_fail1.hs [new file with mode: 0644]
testsuite/tests/partial-sigs/should_fail/T13324_fail1.stderr [new file with mode: 0644]
testsuite/tests/partial-sigs/should_fail/T13324_fail2.hs [new file with mode: 0644]
testsuite/tests/partial-sigs/should_fail/T13324_fail2.stderr [new file with mode: 0644]
testsuite/tests/partial-sigs/should_fail/all.T
utils/haddock