[GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs

[GHC]

#9582: Associated Type Synonyms do not unfold in InstanceSigs
-------------------------------------+-------------------------------------
              Reporter:              |            Owner:
  andreas.abel                       |           Status:  patch
                  Type:  bug         |        Milestone:
              Priority:  normal      |          Version:  7.8.3
             Component:  Compiler    |         Keywords:  InstanceSigs
  (Type checker)                     |  TypeFamilies
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:              |  Related Tickets:
  None/Unknown                       |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by andreas.abel):

 Thanks for the help!

 Now I use PatSigOrigin to swap expected/actual type in the error
 message generated by tcSubType.
 {{{#!hs
                 -- Check that type provided in the type signature
                 -- is both a sub- and a super-type of the type
                 -- originating from the method signature in the class.
                 -- As a consequence, the types are equal, and we can
 discard
                 -- the coercions.  (Keep fingers crossed.)
                 let ctOrigin = AmbigOrigin userTypeCtxt
                 void $ tcSubType ctOrigin userTypeCtxt sig_ty
 local_meth_ty
                 -- In case the provided type is more general than the
 expected
                 -- type, we take care that the error reports actual and
                 -- expected type correctly.
                 -- Using PatSigOrigin does the job, but it is a bit hacky.
                 void $ tcSubType PatSigOrigin userTypeCtxt local_meth_ty
 sig_ty
 }}}
 This does the job, however, is a bit hacky.  I tried a more
 principled solution with TypeEqOrigin,
 {{{#!hs
                let ctOrigin' = TypeEqOrigin
                       { uo_actual   = sig_ty
                       , uo_expected = local_meth_ty
                       }
                 void $ tcSubType ctOrigin' userTypeCtxt local_meth_ty
 sig_ty
 }}}
 but except for PatSigOrigin,
 instances of CtOrigin are ignore in tcSubType, or rather, converted to a
 standard TypeEqOrigin (with expected/actual ordered not in the way I
 want to). See TcUnify.lhs:
 {{{#!hs
 tcSubType :: CtOrigin -> UserTypeCtxt -> TcSigmaType -> TcSigmaType -> TcM
 HsWrapper
 -- Check that ty_actual is more polymorphic than ty_expected
 -- Both arguments might be polytypes, so we must instantiate and skolemise
 -- Returns a wrapper of shape   ty_actual ~ ty_expected
 tcSubType origin ctxt ty_actual ty_expected

 ...  unify ty_actual ty_expected ...

   where
     -- In the case of patterns we call tcSubType with (expected, actual)
     -- rather than (actual, expected).   To get error messages the
     -- right way round we have to fiddle with the origin
     unify ty1 ty2 = uType u_origin ty1 ty2
       where
          u_origin = case origin of
                       PatSigOrigin -> TypeEqOrigin { uo_actual = ty2,
 uo_expected = ty1 }
                       _other       -> TypeEqOrigin { uo_actual = ty1,
 uo_expected = ty2 }
 }}}
  This could be changed of course, bit there is a principal
 risk of breaking something.  In particular, would it not make sense to
 preserve TypeEqOrigin?
 {{{#!hs
                       TypeEqOrigin{} -> u_origin
 }}}
 If you give your OK, I implement this to make my fix of #9582 cleaner.

 Working fix on
 https://github.com/andreasabel/ghc/commit/29a2f93a26f714b79a59617d20b73b2e166cc62c
 some cleaning needed.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9582#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler