Skip to content
  • Ryan Scott's avatar
    Allow PartialTypeSignatures in standalone deriving contexts · affdea82
    Ryan Scott authored
    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
    affdea82