[commit: ghc] wip/rae-new-coercible: Compile; fix a testsuite failure. (494d0db)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : wip/rae-new-coercible
Link       : http://ghc.haskell.org/trac/ghc/changeset/494d0dbb31ca82192fff6585dae39efc2cce2a5f/ghc

>---------------------------------------------------------------

commit 494d0dbb31ca82192fff6585dae39efc2cce2a5f
Author: Richard Eisenberg <eir at cis.upenn.edu>
Date:   Sun Dec 7 22:42:50 2014 -0500

    Compile; fix a testsuite failure.


>---------------------------------------------------------------

494d0dbb31ca82192fff6585dae39efc2cce2a5f
 compiler/typecheck/TcCanonical.hs                      | 12 ++++--------
 compiler/typecheck/TcFlatten.hs                        |  0
 testsuite/tests/indexed-types/should_fail/T9580.stderr |  1 +
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/compiler/typecheck/TcCanonical.hs b/compiler/typecheck/TcCanonical.hs
index 9cc847e..abca349 100644
--- a/compiler/typecheck/TcCanonical.hs
+++ b/compiler/typecheck/TcCanonical.hs
@@ -569,8 +569,7 @@ can_eq_flat_app ev eq_rel swapped s1 t1 ps_ty1 ty2 ps_ty2
            ; xCtEvidence ev (XEvTerm [mkTcEqPred s1 s2, mkTcEqPred t1 t2] xevcomp xevdecomp)
            ; stopWith ev "Decomposed AppTy" }
 
-\end{code}
-
+{-
 Note [Eager reflexivity check]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Suppose we have
@@ -613,8 +612,7 @@ we do a reflexivity check.
 
 (This would be sound in the nominal case, but unnecessary, and I [Richard
 E.] am worried that it would slow down the common case.)
-
-\begin{code}
+-}
 
 ------------------------
 -- | We're able to unwrap a newtype. Update the bits accordingly.
@@ -683,8 +681,7 @@ canDecomposableTyConApp ev eq_rel tc1 tys1 tc2 tys2
   = do { traceTcS "canDecomposableTyConApp" (ppr ev $$ ppr eq_rel $$ ppr tc1 $$ ppr tys1 $$ ppr tys2)
        ; canDecomposableTyConAppOK ev eq_rel tc1 tys1 tys2 }
 
-\end{code}
-
+{-
 Note [Use canEqFailure in canDecomposableTyConApp]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 We must use canEqFailure, not canEqHardFailure here, because there is
@@ -715,8 +712,7 @@ or reinsert them back in appropriately.
 The alternative to this is to have the solver be aware of phantoms and
 solve them in a top-level reaction. That somehow seems worse than just
 a little fiddliness right here.
-
-\begin{code}
+-}
 
 canDecomposableTyConAppOK :: CtEvidence -> EqRel
                           -> TyCon -> [TcType] -> [TcType]
diff --git a/testsuite/tests/indexed-types/should_fail/T9580.stderr b/testsuite/tests/indexed-types/should_fail/T9580.stderr
index f3a884e..fdb457a 100644
--- a/testsuite/tests/indexed-types/should_fail/T9580.stderr
+++ b/testsuite/tests/indexed-types/should_fail/T9580.stderr
@@ -4,6 +4,7 @@
 T9580.hs:7:9:
     Couldn't match representation of type ‘Double’
                              with that of ‘Dimensional Int Double’
+    Relevant role signatures: type role Dimensional nominal nominal
     The data constructor ‘T9580a.Quantity'’
       of newtype ‘Dimensional Int v’ is not in scope
     In the expression: coerce x