Ryan Scott authored Nov 05, 2020 and Marge Bot committed Dec 18, 2020

Issue #18914 revealed that `GeneralizedNewtypeDeriving` would generate code
that mentions unbound type variables, which is dangerously fragile. The
problem (and fix) is described in the new `Wrinkle: Use HsOuterExplicit`
in `Note [GND and QuantifiedConstraints]`. The gist of it: make sure to
put the top-level `forall`s in `deriving`-generated instance signatures in an
`HsOuterExplicit` to ensure that they scope over the bodies of methods
correctly. A side effect of this process is that it will expand any type
synonyms in the instance signature, which will surface any `forall`s that
are hidden underneath type synonyms (such as in the test case for #18914).

While I was in town, I also performed some maintenance on `NewHsTypeX`, which
powers `GeneralizedNewtypeDeriving`:

* I renamed `NewHsTypeX` to `HsCoreTy`, which more accurately describes its
  intended purpose (#15706). I also made `HsCoreTy` a type synonym instead of
  a newtype, as making it a distinct data type wasn't buying us much.
* To make sure that mistakes similar to #18914 do not occur later, I added an
  additional validity check when renaming `HsCoreTy`s that complains if an
  `HsCoreTy`s contains an out-of-scope type variable. See the new
  `Note [Renaming HsCoreTys]` in `GHC.Rename.HsType` for the details.

Fixes #15706. Fixes #18914. Bumps the `haddock` submodule.