Some tidying up of type pretty-printing

Triggered by the changes in #13677, I ended up doing a bit of
refactoring in type pretty-printing.

* We were using TyOpPrec and FunPrec rather inconsitently, so
  I made it consisent.

* That exposed the fact that we were a bit undecided about whether
  to print
     a + b -> c + d   vs   (a+b) -> (c+d)
  and similarly
     a ~ [b] => blah  vs   (a ~ [b]) => blah

  I decided to make TyOpPrec and FunPrec compare equal
  (in BasicTypes), so (->) is treated as equal precedence with
  other type operators, so you get the unambiguous forms above,
  even though they have more parens.

  We could readily reverse this decision.
  See Note [Type operator precedence] in BasicTypes

* I fixed a bug in pretty-printing of HsType where some
  parens were omitted by mistake.

1 files changed, 1 insertions, 1 deletions

diff --git a/testsuite/tests/typecheck/should_fail/T12921.stderr b/testsuite/tests/typecheck/should_fail/T12921.stderr
index 422ec7dbd3..bd0ba8e43d 100644
--- a/testsuite/tests/typecheck/should_fail/T12921.stderr
+++ b/testsuite/tests/typecheck/should_fail/T12921.stderr
@@ -21,7 +21,7 @@ T12921.hs:4:16: error:
                                   p0)’ from being solved.
       Probable fix: use a type annotation to specify what ‘p0’ should be.
       These potential instances exist:
-        instance a ~ Char => Data.String.IsString [a]
+        instance (a ~ Char) => Data.String.IsString [a]
           -- Defined in ‘Data.String’
         ...plus two instances involving out-of-scope types
         (use -fprint-potential-instances to see them all)